help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C++ / multiple instances / iostreams


From: Detlef Vollmann
Subject: Re: C++ / multiple instances / iostreams
Date: Sat, 24 Jul 2004 11:06:24 +0200

Hans Aberg wrote:
> At 11:51 +0200 2004/07/23, Detlef Vollmann wrote:

> >  The table approach has no overhead in term of run-time
> >(as long as no exception is thrown), but in program text size
> >(they use a table that is typically left on disk as long as it
> >is not used).
> 
> But I have a memory of that some experts said that also such approaches
> actually had an time overhead.
See the Perfomance Report
 http://www.open-std.org/jtc1/sc22/open/n3646.pdf
for a detailed description and analysis.
The bottom line is, that as long as you don't throw exceptions,
you have no time overhead.  On the first exception you actually
throw, you get a huge overhead, as the table needs to be loaded.
Later exceptions get a moderate overhead.

> 
> If I should take an example which is directly to the implementation of the
> Bison C and C++ parsers, a question that pops up in this list from time to
> time, then it the question of a dynamic parser stack:
> 
> Under C, all struct data is POD, so it needs not to invoke any copy
> constructors, so the whole stack can be re-copied in one go.
Hmmm, if I look at my C++ skeleton for byacc, I don't see the need
for copying the whole stack.  The only multi-element operation
I use is on a reduction with a length > 1.  All others modifying
operations are only single-element push and pop.

But in general, you're right: That multi-element erase needs to
call the destructors for all the elements, while a C stack could
just adjust the top pointer of the stack.
The good news is, that if the destructors are actually NOPs,
most optimizing compilers will eliminate the whole loop for
the destructors, so in this case C and C++ produce effectively
the same code.
For adding multiple elements, the same optimizations is possible.
So in these cases, the base performance rule for C++ holds:
You don't pay, for what you don't need.

In the case of copying a whole stack, in C you can just do a
memcpy, while in C++ you need to loop over the elements and
copy them one by one.  If the value type of the stack is a POD,
the element cpoies can be memcpys, but to join those single
memcpys into one overall memcpy is something that most optimizers
don't do.
Whether there is a measurable performance difference between the
single memcpys and one big memcpy is another question...

Of cause, all these discussions assume that you use some template
for the stack.

Detlef

-- 
Detlef Vollmann   vollmann engineering gmbh
Linux and C++ for Embedded Systems    http://www.vollmann.ch/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]