2009/5/25 <[email protected]>: > > Since resolving the scoping issues causing access violations earlier > in the week, I've been running some comparisons against c++ native > functions, and other interpretive engines, specifically muParser. > > The good news is that string manipulation looked pretty fast -- 50,000 > looped regexes in a JS function passed to the V8 wrapper ran in about > 0.19 seconds versus 0.14 seconds against our C++ PCRE wrapper. Not bad > at all, very happy with that, as PCRE is known to be a very fast > library with all kinds of speedup tricks.
Actually I would have expected us to do better than that. Care to share your test? > However, running simple *math* expressions into the V8 wrapper yields > a very different result. I've got a math-specific wrapper in the code > too (have had it since before V8 came along; didn't need to be general > purpose) which uses muParser (http://muparser.sourceforge.net/) as its > underlying engine. So, I created a few basic equations and ran the > against each other. > > The typical sort of expressions used would look like this... > >>> function speed_test(x){ return (x+x) /3; } > > ...where 'speed_test' is called in a loop where 'x' is incremented > from 1 to 50,000. > > muParser, which compiles down to bytecode, is consistently 12 times > faster than V8 for all kinds of math expressions that I've tried, > which I definitely didn't expect. Judging by the results from the > regex test I've got a reasonably well optimised wrapper in place. The > only difference between one test and the other is the function being > executed -- one does string manipulation, one does math. Nothing in > the wrapper is called any differently. > > Is this result expected? Is V8 heavily optimised towards strings and > known to be slower at math? Or is there something I can do to improve > matters? I can't believe that V8 is that much slower, but I also can't > see why the wrapper I've implemented would be close to optimal with a > string function, while being so far away with math... You should probably do some tests with a slightly larger function to see how much is the call overhead and how much is the actual execution of the math operations. You could also use the profiler support built into V8 to see where the time is going. That said, JavaScript isn't a particularly efficient language for math operations. Since it is completely dynamically typed, everything in JS is an object (or a value, but there's not much difference at the implementation level). Therefore, most implementations (including V8) will 'box' all floating point numbers, ie allocate a small object to contain them. This allocation overhead is hard to optimize away. I'm not saying it can't be improved, but you shouldn't expect miracles in fp performance. -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
