Nick Lawson wrote:
> Ok, NO overhead for try..catch is an exaggeration. But only a small one
> - typically there is exactly one extra bytecode instruction per try,
> to branch round the catch{} clauses....
>
> I guess the question was whether try..catch is faster or slower
> than the alternatives. I think the program below is more
> like the sort of situation that occurs in real life.
To which the answer turns out to be highly dependent on the app. In the
case of our examples, the exceptional condition truly is exceptional
(given its 0% probability), and the best solution is a try/catch outside
of the inner loop and no test.
I tried to get a closer look at where time was being spent, by running
my example with -Xrunhprof:samples. Blackdown reported that all of the
time was spent in the Date() assignments immediately before each loop,
suggesting some flaws with the profiling implementation and/or
reporting.
Pretty impressive optimization on symcjit, though it smells a bit like a
compiler that's been tuned to the benchmarks. Does it perform that well
on real applications?
Nathan
> The times for this (Pentium 166, Sun Windows 95 JDK 1.2, Blackdown 1.2pre-v2
> + glibc 2.1 + OpenLinux 2.2,
> 500,000,000 iterations):
>
> VM: kaffe Sun Sun Blackdown Blackdown
> JIT: symcjit none sunwjit none
> ----- ------- ---- --------- ----------
> With try/catch 388,212 12,360 545,410 136,207 466,300
> Without 396,401 15,490 601,000 143,784 508,770
>
> %faster 2% 20% 9.2% 5.2% 8.3%
>
> - the last column is estimated from 50,000,000 iterations.
>
> .
> .
> .
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
