surprising template size and speed

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

"File not found" and "Null pointer" exceptions which are common in java
are definitly not exceptional conditions - file not found is common and
"null pointer" should be handled as an error.

I think file not found is almost always an exceptional condition, no matter
how frequently it happens. In an interactive program the response to that
condition will be to inform the user, in a non interactive usually to abort
or write to some error log. These actions are not part of the main flow of
the program, nor suffer any harm for the minimal delay the exception
handling can have even with the compilers worse in this aspect.

Surely one can imagine a directory reading utility that tries to open all
possible file names, and returns the names in which the open succeed. Here
a delay caused by exception handling if the "file not found" condition is
handled that way can be significant. But in this case, and other more
realistic of the same type, put the blame in the inadequate algorithm used,
not in the exception handling.

A null pointer is like have a 0 value in an integer: It can be exceptional,
a symptom of a serious flaw or a perfectly normal condition, depending of
what each concrete functions than handle pointers expects.

The same thing with any other general condition. A 'end of file reached' is
a perfectly normal event when reading a text file, but is abnormal when
reading a fixed size field in a binary file with well defined format.

 

[VaderX]

"may be" is the key sequence there. Implementations have vastly
improved since the early 90's.


When examining the costs of exceptions you need to compare it to
alternative methods of error handling, not to simple function
returning. There are two viable alternatives:

1) error code returns.
These must be checked and can be ignored leaving the program in an
unkowingly erroneous state.
2) error code globals
lots of problems there.

Either one must have error checking in the form of ifs all over the
place; often times several levels of them because you catch an error,
need to stop, and return that error up the call stack. Exceptions
handle this kind of thing quite well. The question is, are the ifs
that much less of a performance hit?



memory/resource leaks have nothing to do with exceptions. Have you
compared the cleanliness of exceptions vs return codes and have you
compared the performance of exceptions to error code checking
"everywhere"?


That is an illogical mandate. The callee can't know who best can
handle the errors it generates. Obviously it returns an error because
for some reason it can't deal with it on its own...why attempt to
enforce a relationship that is possibly not valid?


Not true...the caller can just ignore them. Exceptions cannot be
ignored.


As can error codes except that once ignored there is no way to know
that an error occured. Exceptions will pull up the stack until handled
and cannot be ignored.


That assumes that exceptions cause a performance penalty such that
error handling using them is too much penalty for high performance
systems. There is no indication that you have measured this penalty
and seem to be simply making miles and miles of assumptions based on no
data whatsoever.

There are two things to consider: Do exceptions really cause a penalty
that so outweighs error code handling that one is better than the other
performance wise; this is highly questionable. Second, is your system
such that it needs to be able to deal with erroneous conditions as
quickly as the mainline, which has to be very fast; this is extreemly
rare.

Another thing to consider...do the mainline and error path have equal
performance requirements? If not, could the mainline be made faster by
not having error handling code in it? If so, even if exceptions are
slower maybe they are the better alternative.

You make several good points and I was especially struck by your last
one (the different requirements for mainline and error paths). I will
do some more research on exception costs but right now I'm still
working on the template front.
I don't want to give the impression that my manager is not open to
change. He's a smart guy, has been programming a long time now (20+
years) and is willing to listen if I can convince him. Which is why I'm
spending the time and effort to evaluate templates and their
performance impact.

 

[charles]

Here you do 1000000 memory allocations


And here you do 2000000 memory allocations.

In the std::vector version there will only be a handful of allocations.
This could explain the differences you are seeing.

Yes that could be it - in fact in the previous post (frame) wrote a
memory-managed list class that actually out-performed vector (for this
specific case)

 

[Lionel B]

Sadly I have no chance of selling the usage of std::list without first
proving that templates are not evil. Plus we do not use exceptions in
our code and the overhead of exception usage is not acceptable to our
company. I did try the std::vector (which was bigger but faster).

[...]

And there you go...if you use the STL you will have to enable
exceptions (if you're even turning them off) and thus will have all the
costs associated with them. Any size increase for tables, any call
overhead for functions...etc...will all be paid if you use the STL.

To add to this: with gcc for example you can compile with a
-fno-exceptions flag. Of the obverse -fexceptions flag the manual states:

"Enable exception handling. Generates extra code needed to propagate
exceptions. For some targets, this implies GCC will generate frame
unwind information for all functions, which can produce significant
data size overhead, although it does not affect execution."

This is all a bit vague and of course implementation-dependent. What I
have found in practice on my system is that with -fno-exceptions you can
still compile code (including STL code) that throws exceptions... what you
cannot do is catch them (code will not compile). It seems that on a throw
a default catch kicks in which simply prints out the exception and aborts
the program.

I tried both flags on a sample program of mine that makes very heavy use
of STL containers (including throwing calls such as vector::at()) but
doesn't catch exceptions. There was indiscernible difference in either
program size or execution speed.

 

[Lionel B]

(e-mail address removed) wrote:

[snip]

I don't want to give the impression that my manager is not open to
change. He's a smart guy, has been programming a long time now (20+
years) and is willing to listen if I can convince him. Which is why I'm
spending the time and effort to evaluate templates and their
performance impact.

Well hey, point him at this thread! At the very least he can't fail to be
impressed by your diligence

 

[charles]

(e-mail address removed) wrote:

[snip]

I don't want to give the impression that my manager is not open to
change. He's a smart guy, has been programming a long time now (20+
years) and is willing to listen if I can convince him. Which is why I'm
spending the time and effort to evaluate templates and their
performance impact.

Well hey, point him at this thread! At the very least he can't fail to be
impressed by your diligence

I'll do that!