On Sun, 19 Dec 2010 07:33:29 -0500, spir <denis.s...@gmail.com> wrote:
Hello,
I had not initially noticed that the 'in' operator (for AAs) returns a
pointer to the looked up element. So that, to avoid double lookup in
cases where lookups may fail, I naively used try...catch. In cases of
very numerous lookups, my code suddenly became blitz fast. So that I
wondered about exception handling efficiency. Below a test case (on my
computer, both loops run in about the same average time):
void main () {
byte[uint] table = [3:1, 33:1, 333:1];
byte b;
byte* p;
Time t0;
uint N1 = 246, N2 = 9999999;
// try...catch
t0 = time();
foreach (n ; 0..N1) {
try b = table[n];
catch (RangeError e) {}
}
writefln("try...catch version time: %sms", time() - t0);
// pointer
t0 = time();
foreach (n ; 0..N2) {
p = (n in table);
if (p) b = table[n];
}
writefln("pointer version time: %sms", time() - t0);
writefln("pointer version is about %s times faster",N2/N1);
}
==>
try...catch version time: 387ms
pointer version time: 388ms
pointer version is about 40650 times faster
Note that both versions perform a single lookup trial; the difference
thus only lies in pointer deref vs try...catch handling, i guess. What
do you think?
This example is misleading. First, catching an exception should be a rare
occurrence (literally, an exception to the rule). You are testing the
case where catching an exception vastly outweighs the cases where an
exception is not thrown. What I'm saying is, catching an exception is
very slow, but *trying* to catch an exception is not.
Second, exception handling is not meant to be used in the way you used
it. You don't use it as an extra return value. I'd expect a more
reasonable use of catching an exception in AAs as this:
try
{
foreach(n ; 0..N1)
{
b = table[n];
}
}
catch(RangeError e)
{
writeln("Caught exception! ", e);
}
An exception is a recoverable error, but it usually means something is
wrong, not 'business as usual'. This doesn't mean it's impossible to
design poor interfaces that use exceptions for everything, but it
shouldn't be that way. An exception should always be a rare occurrence,
when something happens that you don't expect. A huge clue that you are
using exceptions poorly or that the interface is not meant to be used that
way is if your exception handling is being done at the innermost level of
your program. Exception handling is great when it exists at a much higher
level, because you can essentially do all error handling in one spot, and
simply write code without worrying about error codes.
This is why the 'in' operator exists for AAs.
General rules of thumb for AAs:
1. if you expect that a value is always going to be present when you ask
for it, use exception handling at a high level.
2. if you *don't* expect that, and want to check the existence of an
element, use 'in'
Now, after saying all that, improving how exception handling works can
only be good. So comparing exception handling performance in D to
exception handling in other languages can give a better idea of how well
D's exception handling performs.
-Steve
