[haiku-appserver] Re: performance considerations
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Tue, 20 Sep 2005 14:12:29 +0200
On 2005-09-20 at 01:12:47 [+0200], Adi Oanca wrote:
>
> I know that what you have to say about this, but I wanted to touch this
> subject for a very long time.
>
> I think that some aspects of optimizations should be taken into account
> from early times like the beginnings. Others should be left when near
> the release of a product.
>
> There are some simple optimizations that we can make now and not let
> them wait for the release date.
>
> For example, take the following piece of code:
[...]
> 500% slowdown in the first case, which is used a lot more often in our code.
>
> Couldn't we optimize the code when first writing it?
There are cases where that is definitely justified. E.g. when you implement a
general algorithm (sorting, searching) for BList. But in most cases it isn't.
In your example above it might be. If you really have many items and compute
something simple over them, then it is. If your computation is more complex
-- as soon as you call another method it probably is -- the time the
computation takes will outweigh the ItemAt() overhead. E.g. if your
computation takes 10 times as long as an ItemAt(), what you gain by direct
array access are not even 8 percent.
And mind you, ItemAt() is safer, not only because it does bounds checking --
it might not matter, whether you access memory out of the array or a
dereference the NULL pointer ItemAt() returns (save that the latter is "fail
fast" which is usually preferrable) -- but also, because it is robust against
modifications of the list (if you add/remove something, the array might be
realloc()ated and the array pointer you got before might become invalid).
That being said, if you write code and suspect, it could become a performance
bottle neck, a simple optimization as in your example might not harm, but in
general I would refrain from early optimizing. Especially if it could affect
code robustness and readability. Always keep in mind that you might not be
the last one touching the code you write.
CU, Ingo
Other related posts:
