FreeLists / haiku-appserver / [haiku-appserver] Re: BScreen support

[Adi Oanca <adioanca@xxxxxxxxxxxxx>]

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.