692009 - Peacekeeper stringValidateForm is really slow

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Trev]

Attachment: stringValidateForm

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0a2) Gecko/20111004 Firefox/9.0a2
Build ID: 20111004042012

Steps to reproduce:

In the peacekeeper stringValidateForm, all of the regular expressions are slower in Firefox (Aurora) vs Chrome.  I've made a test case that runs the code.  My numbers are:

Firefox: elapsed time: 195
Chrome: elapsed time: 71

This is one of the worst peacekeeper tests

Comment 1

[Jan de Mooij [:jandem]]

Attachment: Shell testcase

Simple shell testcase. The bad news:

d8:  575 ms
SM: 1088 ms

The good news: we are about as fast as v8 on 4 of the 5 regular expressions now. The bad one is the email check, with that one commented out:

d8: 391 ms
SM: 387 ms

So what we need to make fast is this:

function test() {
    var t = new Date;
    for (var i = 0; i < 1000000; i++) {
	input = "[e-mail]";
	result = /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(input);
    }
    print(new Date - t);
}
test();

d8: 173 ms
SM: 670 ms

And indeed, a profile shows we're spending most time in Yarr::Interpreter::* :(

Comment 2

[Jan de Mooij [:jandem]]

Hannes do you happen to know why Yarr does not JIT this regular expression? Asking you because you've also looked into Octane-regexp.

Comment 3

[Jan de Mooij [:jandem]]

Attachment: Shell testcase

Eh previous attachment had the bad regex commented out. Oops.

Comment 4

[Hannes Verschore [:h4writer]]

(In reply to Jan de Mooij [:jandem] from comment #2)
> Hannes do you happen to know why Yarr does not JIT this regular expression?
> Asking you because you've also looked into Octane-regexp.

We are failing due to this:
        // We can currently only compile quantity 1 subpatterns that are
        // not copies. We generate a copy in the case of a range quantifier,
        // e.g. /(?:x){3,9}/, or /(?:x)+/ (These are effectively expanded to
        // /(?:x){3,3}(?:x){0,6}/ and /(?:x)(?:x)*/ repectively). The problem
        // comes where the subpattern is capturing, in which case we would
        // need to restore the capture from the first subpattern upon a
        // failure in the second.

/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(input);

So we can't compile due to capturing subpattern atm.
(anything)+ or (anything){4,7} are a problem and we stay in the interpreter.

Comment 5

[Jan de Mooij [:jandem]]

Filed a WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=122891

Comment 6

[Hannes Verschore [:h4writer]]

Bug 976446 will change this:

Before:
benchmark Elapsed time 50. Operations: 50000. Operations per second: 1000000

After:
benchmark Elapsed time 42. Operations: 50000. Operations per second: 1190476.1904761903

Chrome is still king here:
benchmark Elapsed time 26. Operations: 50000. Operations per second: 1923076.9230769232

We assume this might be caused by the fact we have 16bit chars and chrome 8bit chars

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

On 64bit linux, Nightly 42, Chrome 37.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Operations per second: 1724137 on Nightly, Chrome Operations per second: 1612903