i was doing some parser benchmarks today and noticed that i took a big
(20%) performance hit on my tests when i wrapped my parse function in
a try catch. i did some googling and came across this:

http://code.google.com/p/v8/issues/detail?id=1065

"Because of the with or try/catch we allocate all the parameters and
locals in the heap."

just thought people should be aware of it and hopefully it's something
that can be addressed...

yikes :s

Hi Billy,
Think you can share your tests?

--
Zachary Scott

Zachary, i don't have an easy to post code but i was testing my
fastcgi parser here: https://github.com/billywhizz/node-fastcgi-parser.

if you clone it and check out master you should be able to reproduce
by running

node benchmark/createtestfiles.js 1000000

to create the test files and

node benchmark/speed-fcgi.js out 16
node benchmark/speed-fcgi.js in 16

to run the performance tests.

run the same tests again after putting a try/catch around the
Parser.execute method in lib/parser.js and you should see a big
performance hit. on my setup (fedora 12/64 on Core 2 Quad Q8200  @
2.33GHz) i get the following numbers:

without try/catch:
Rec:153021, Time: 1002, Rec/Sec: 152716, MBit/Sec: 152
Rec:147706, Time: 1000, Rec/Sec: 147706, MBit/Sec: 147
Rec:149207, Time: 1000, Rec/Sec: 149207, MBit/Sec: 149
Rec:151146, Time: 1001, Rec/Sec: 150995, MBit/Sec: 150
Rec:150270, Time: 999, Rec/Sec: 150420, MBit/Sec: 150
Rec:152896, Time: 1000, Rec/Sec: 152896, MBit/Sec: 152

with try/catch:
Rec:125318, Time: 1003, Rec/Sec: 124943, MBit/Sec: 124
Rec:121817, Time: 1000, Rec/Sec: 121817, MBit/Sec: 121
Rec:124256, Time: 1000, Rec/Sec: 124256, MBit/Sec: 124
Rec:124443, Time: 1000, Rec/Sec: 124443, MBit/Sec: 124
Rec:124319, Time: 999, Rec/Sec: 124443, MBit/Sec: 124
Rec:123943, Time: 1000, Rec/Sec: 123943, MBit/Sec: 123
Rec:124193, Time: 1000, Rec/Sec: 124193, MBit/Sec: 124
Rec:124693, Time: 1000, Rec/Sec: 124693, MBit/Sec: 124

i'll see if i can reduce the test to something gist-able...

On Feb 20, 5:19 am, Zachary Scott <zachary.s.sc...@gmail.com> wrote:
> Hi Billy,
> Think you can share your tests?
>

right, i've stuck a gist up here: https://gist.github.com/836387 which
shows the issue quite well.

the upshot of it seems to be that if you have a function that has
performance critical code in it (particularly if it's allocating a lot
of variables), then don't use a try/catch inside the function and
catch the errors from outside the function instead.

Interesting... thanks for sharing!
Will try to avoid this in the future :)

Wow, that sucks.  Very good to know though.

yes. would be nice to have a best practices page on the wiki along
with a bunch of performance tests which we can monitor with each new
release of v8... maybe we should create as a separate repo for now and
we can add it to the main repo at some stage if there is agreement to
do so...?

+1 for node/v8 best practices doc

Boom, done.

Holy crap, check out the jump in performance between firefox 4 beta11 and beta12 (attached).  Might be an outlier because only 1 test on beta12, but still.

Were those from the same machine? Sometimes the speed is misleading, the % diff between tests is what is actually telling on jsperf.

Good point.  I'm sure it shouldn't be taken at face value.  But the performance on FF 4 has been increasing steadily.  v8 and node.js notwithstanding, I still prefer Firefox to Chrome for a few key reasons.  I want them to get back in the game and be competitive.