Closed Bug 502058 Opened 15 years ago Closed 14 years ago
TM: Severe performance deterioration of String
.match with complex regex
OS: Windows Vista → All
Hardware: x86 → All
Summary: TraceMonkey: Severe performance deterioration of String.match with complex regex → TM: Severe performance deterioration of String.match with complex regex
Version: unspecified → 1.9.1 Branch
The problem is related to this code in RegExpNativeCompiler::compile: /* * If the regexp is too long nanojit will assert when we * try to insert the guard record. */ if (re_length > 1024) return JS_FALSE; The regexp in this test case is longer that 1024, so we exit here. But the fragment doesn't get blacklisted, so we keep trying to compile it again and again. Each compilation is only about 100,000 cycles, but we run so many of them (repeating the match operation globally on a string of increasing length) that they add up. I tried adding "fragment->blacklist()" to the code above, but that doesn't work. Because of the way the regexp identity is stored in a fragment, it ends up not getting stored in this case, so we don't find the blacklisted fragment ever, and keep trying to compile over and over. Instead, I decided to use a free flag bit in JSRegExp to record the fact that we can't compile the regexp and shouldn't try again. This also allows us to bail out of the native compilation path faster than before.
Assignee: general → dmandelin
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #386612 - Flags: review?(gal)
Comment on attachment 386612 [details] [diff] [review] Patch Time to move this stuff out of the lir.
Attachment #386612 - Flags: review?(gal) → review+
Pushed to TM as 24ea6a78f889.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment on attachment 425345 [details] [diff] [review] Patch rebased for 1.9.1 (context changed only) a=beltzner for 1.9.1
Attachment #425345 - Flags: approval126.96.36.199? → approval188.8.131.52+
You need to log in before you can comment on or make changes to this bug.