On Thu, 5 May 2005, Adi Oanca wrote: > Stephan Assmus wrote: > >> Otherwise it is a ridiculous discussion. And before we >> even worry about performance at all, we need a correct implementation. >> Anything else is premature optimization. > > Do not agree. At least in the context of our discussion. A good design > should be enforced from the start. If we did not had a SMP friendly design > final optimizations could not get as much performance of a SMP machine if we > did not take that into account. According to my experience it's not a good idea trying to start with a `perfect' design for large or even medium sized systems. Unless you have already implemented such a system before and now know all the issues and pitfalls, that's virtually impossible. It's almost garuanteed that you'll need to redesign and refactor parts. Hence starting with a reasonable design -- that doesn't even need to consider all features (as long as it is open enough not to rule them out) and should definitely not be optimized to `maybe be more performant in some situations' -- and refine and refactor it as you go is usually the better strategy. Really, don't optimize until you know that optimization is needed and the one you have in mind really improves things. If you have two possible algorithms/designs choose the less complex one, unless you're sure the other one is better and needed and cannot be easily derived from the first one. And not only theoretically better -- e.g. an O(n^2) algorithm can be a better solution for a specific problem than one that is O(n). As Stephan says, ideally you first do a correct implementation and then check what needs to be optimized. This has the nice side-effect, that you'll earlier have something that works (especially in a context like this, where other people depend on what you do). Just ask Axel, how many parts of the kernel work, but are far from being optimal (or just good). :-) CU, Ingo