[haiku-appserver] Re: [Haiku-commits] r14599 - haiku/trunk/src/servers/app

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Tue, 01 Nov 2005 00:40:32 +0100 CET

Adi Oanca <adioanca@xxxxxxxxx> wrote:
> Ingo Weinhold wrote:
> > On 2005-10-31 at 21:50:20 [+0100], Adi Oanca wrote:
> > [...]
> >>    What if we avoid programming with exceptions and compile the 
> > > app_server
> >>without exceptions support? This should get us some speed...
> >>Is it possible?
> > It is possible, though. Whether it really gains a lot is another 
> > thing. AFAIK 
> > the overhead of using exceptions is not really relevant (if there 
> > is overhead 
> > at all -- you have to do error checking anyway). Throwing 
> > exceptions can be 
> > rather expensive, though, which is why one should use them only for 
> > really 
> > exceptional cases.
>       Which is... almost never. :-)

Exactly, for example when an allocation fails. I don't think that 
exceptions have a big overhead, especially as long as you don't use 
them :-)

> >>    To avoid a few CPU cycles please pull out local declarations 
> > > from loops.
> > Please don't do something like this; keeping variables as local as 
> > possible 
> > increases the readability. Furthermore trust the compiler. Don't 
> > try to trick 
> > it -- it's your friend. Extending the scope of a variable may cause 
> > a bigger 
> > stack footprint and may even make your code slower, since the 
> > compiler has 
> > less knowledge it can apply.
>       Umm... I don't think so. At least my tests and the books I read 
> point 
> this as a very simple method of optimizing code.
>     (readability is down with 5% - not even noticeable)
>     (the stack footprint ain't bigger at all. one variable put on 
> stack 
> once VS. the same variable pushed an pop-ed many times)

The stack footprint is definitely lowered when you declare variables 
locally.
Just imagine the following case:
        go_work();      // called with a small stack frame
        for (...) {
                char name[256];
                go_work();      // called with a much larger stack frame
        }

You probably just mean:
        char a[16];
        go_work();

        char b[16];
        go_work();

But even there, the compiler has the possibility to call go_work() with 
different stack footprints, if it can. That doesn't mean that GCC does 
this, but the compiler definitely has the option of doing so, and 
that's a good thing.
OTOH I can't imagine how pulling variables out of the local context can 
increase speed, even if only a few cycles -- especially if GCC is as 
lazy as you say and doesn't lower the stack footprint when it could.

>       Also, this code:
>  >>>+            while (fDesktops.CountItems() > 0) {
>  >>>+                Desktop *desktop = fDesktops.RemoveItemAt(0);
>       is not optimal at all.
>       I'm not saying we should optimize at this stage, but you know, you 
> were 
> the one who said that simple optimizations should find their way at 
> the 
> time the code is written.

True, but there will never be a lot of Desktops around. For everything 
in the league "less than 100" it probably doesn't matter a lot, anyway. 
That's usually not where I would start optimizing.

Bye,
   Axel.


Other related posts: