On 2010-12-19 08:17:07 -0500, spir <denis.s...@gmail.com> said:
On Sun, 19 Dec 2010 07:46:09 -0500
bearophile <bearophileh...@lycos.com> wrote:
spir:
try...catch version time: 387ms
pointer version time: 388ms
pointer version is about 40650 times faster
Those numbers look wrong :-)
I thought so. But in the real app a loop that lasted ~ 10s suddenly became
instantaneous (human perception ;-)
Try it. Sorry, but I'm not inventing the numbers.
What looks wrong is that the output seem to say that 388ms was 40650
times faster than 387ms. Obviously, by looking at the code one can
understand that you adjusted the number of iteration to get the same
time for both versions, and from that number of iteration you can claim
the pointer version is about X times faster. But the output alone is
misleading. Add the iteration count to the output and it'll be easier
to read.
Exceptions are slow, that's a fact of life. The idea is that an
exception should be exceptional, so the case to optimize for is the
case where you don't have any exception: a try...catch that doesn't
throw. Other ways to implement exceptions exists which are faster at
throwing (setjmp for instance), but they're also slower at entering and
exiting a try..catch block when no exception occur.
What do you think?
Compared to Oracle Java VM the DMD exceptions are very slow. Performance
tuning of DMD is left for later, when the main features are all present.
And what if the numbers are correct? Exception handling is explicitely reco
mmanded in some docs --as opposed to C-like "manual" hacks.
Exceptions are recommended to avoid cluttering your normal code flow
with error handling code. Clearly, in the code above exceptions are
part of the normal code flow. That's not what exception are made for.
That said, I'd encourage you to profile this test case to see where the
time is being spent. You might find one or two places that can be
improved in the part of the runtime dedicated to exceptions.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
