Peacekeeper stringValidateForm is really slow




JavaScript Engine
6 years ago
3 years ago


(Reporter: Trev, Unassigned)


(Blocks: 1 bug)

9 Branch
Windows XP

Firefox Tracking Flags

(Not tracked)



(2 attachments, 1 obsolete attachment)

2.42 KB, text/html
664 bytes, application/x-javascript


6 years ago
Created attachment 564742 [details]

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


6 years ago
Attachment #564742 - Attachment mime type: text/plain → text/html


6 years ago
Blocks: 499198
Ever confirmed: true
Created attachment 806612 [details]
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 = "";
	result = /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(input);
    print(new Date - t);

d8: 173 ms
SM: 670 ms

And indeed, a profile shows we're spending most time in Yarr::Interpreter::* :(
Hannes do you happen to know why Yarr does not JIT this regular expression? Asking you because you've also looked into Octane-regexp.
Flags: needinfo?(hv1989)
Created attachment 806620 [details]
Shell testcase

Eh previous attachment had the bad regex commented out. Oops.
Attachment #806612 - Attachment is obsolete: true
(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.


So we can't compile due to capturing subpattern atm.
(anything)+ or (anything){4,7} are a problem and we stay in the interpreter.
Flags: needinfo?(hv1989)
Filed a WebKit bug:
Bug 976446 will change this:

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

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


3 years ago
Assignee: general → nobody
On 64bit linux, Nightly 42, Chrome 37.
You need to log in before you can comment on or make changes to this bug.