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.