Ingo Weinhold wrote: > 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. What you say is very true. My experience thought me exactly the same. Is just that I'm tired of redesigned things after I know all the issues and pitfalls, I'm trying to change that on me. I want to have all the things thought out before I begin developing the algorithm/implementation, I want to avoid the second, third design, that costs time and sometimes money. I think that in a short time UML may become one of my close friends. > 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. That sounds good also. > 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. OK, no optimizations. :-) > 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). > :-) :-)) OK, thanks for this mail. bye, Adi.