Hi Julian, I'm not sure what you have tried. But I tried your hardcoded version. (i.e. defining RegExpJS ourself, with the ^ba hack)
- octane1.0-regexp: before: 4510 after: 4658 - octane2.0-regexp: before: 2585 after: 2390 So in octane1.0 that is indeed an improvement. For octane2.0 not and that has a reason. In octane2.0 all calls to "exec()" have a wrapper: "Exec()" that does some extra testing to make sure the result is correct. Using TypeInformation we can find out this is only called with "RegExp" as first parameter. So we can optimize that. Now with "new RegExpJS(/^ba/);" we see 2 signatures in "Exec". So it is less specialized (not much, just an extra if to distinguish the paths at the "exec" call). I'm sure if all regexps would be transformed to "RegExpJS" we would get that back. It would only see 1 signature again. Now about RegExp.JS bringing such a big loss. That is possible. Yarr isn't bad and in octane-regexp we only are stuck in the interpreter for 3% and even in that case the interpreter isn't that slow. We wouldn't win much on octane-regexp if we could JIT everything (what the problem is for the other benchmarks like jQuery and Peacekeeper). It will bring maximum a 4% gain for octane-regexp. Though I would suggest to try to run the numbers again, since the numbers differ so much from mine. Best Hannes On Sun, Jan 5, 2014 at 11:31 AM, <[email protected]> wrote: > On Thursday, January 2, 2014 6:47:58 PM UTC+1, Nicolas Pierron wrote: >> On 01/02/2014 07:31 AM, Nicolas B. Pierron wrote: >> >> I should have wrote that with a past tense … >> >> https://github.com/jviereck/regexp.js > > So far I hadn't done any performance numbers for RegExp.JS. I looked into > this and thanks to the help of Till I got the Octane benchmark running in the > JS shell [1]. > > Before converting the entire Octane RegExp benchmark to run using RegExp.JS I > thought I just try the first RegExp tested in the benchmark. This means the > in terms of code changes: > > diff --git a/regexp.js b/regexp.js > - var re0 = /^ba/; > + var re0 = new RegExpJS(/^ba/); > > Just changing this one RegExp caused the score from ~1480 on my machine to > drop to 77 (!!!) using the RegExp.JS library (& my.mood = :( ). > > Okay, so maybe RegExp.JS is doing something completely wrong, which is why I > tried another dump approach and defined: > > function RegExpJS(reg) { } > > RegExpJS.prototype.exec = function(str) { > if (str.startsWith('ba')) { > return ['ba']; > } else { > return null; > } > } > > This RegExpJS object ONLY works HARDCODED with the first regexp of the octane > benchmark (/^ba/) - cheating, I know, but let's see where this gets us in > terms of performance. Running the regexp.js benchmark with this RegExpJS > definition and the modification |var re0 = new RegExpJS(/^ba/);| resulted in > a score of ~1340. Better than 77, but still a huge drop compared to 1480 by > only changing one RegExp in the benchmark! > > (If you wonder if replacing the |if(str.startsWith('ba'))| call with |if > (str[0] == 'b' && str[1] == 'a') {| --- no, that doesn't make any difference > in terms of performance :/). > > --- > > Without knowing anything about the Spidermonkey JS internals, this very small > benchmarking raises the following questions to me: > > 1) Is the YARR implementation so much faster than anything written in plane > JS (even if the JS is highly optimized for the RegExp and matches the string > in the best optimial way)? > 2) Is there a performance bug in Spidermonkey, that makes even the plain > RegExpJS running only /^ba/ such slow? > > > > Cheers, > > - Julian > > > > > [1] Using the js shell provided at > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ dated on > the 04-Jan-2014 11:50. > > > > _______________________________________________ > dev-tech-js-engine-internals mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
