No expected performance regressions. The not_at_start field is only on ChoiceNode
http://codereview.chromium.org/19539/diff/1/2 File src/ast.cc (right): http://codereview.chromium.org/19539/diff/1/2#newcode257 Line 257: if (node->max_match() > 0) { return false; } It will actually work for min_match too. We currently compute whether the expression contain an initial anchor. If we change our goal to computing whether the expression contains an unguarded anchor (i.e., one that must definitly be matched for the expression to match), then it will be effectively the same, and we can even ignore the min_match check entirely - however, on non-stupid expressions, this check will likely save some time. http://codereview.chromium.org/19539/diff/1/5 File src/jsregexp.cc (right): http://codereview.chromium.org/19539/diff/1/5#newcode3156 Line 3156: bool all_omitted = true; On 2009/02/02 21:22:01, Erik Corry wrote: > I think you can omit this if you implement the suggestions below. Done. http://codereview.chromium.org/19539/diff/1/5#newcode3196 Line 3196: } else if (alt_gen->quick_check_details.cannot_match()) { And I should. I think it's a bug that it doesn't do anything special if the last case is omitted. http://codereview.chromium.org/19539/diff/1/5#newcode3971 Line 3971: 0, new_max, is_greedy, body, compiler, on_success, not_at_start); On 2009/02/02 21:22:01, Erik Corry wrote: > not_at_start can be true here since we know that min > 0 and body can't be > empty. Done. http://codereview.chromium.org/19539/diff/1/5#newcode4839 Line 4839: // Unroll once, and tell the loop that it's not at the start of the input. Ah, yes. Refactoring breaks comments. http://codereview.chromium.org/19539/diff/1/6 File src/jsregexp.h (right): http://codereview.chromium.org/19539/diff/1/6#newcode1199 Line 1199: cp_offset_ == 0 && On 2009/02/02 21:22:01, Erik Corry wrote: > A trace is not trivial unless at_start_ is UNKNOWN. Done. http://codereview.chromium.org/19539/diff/1/7 File src/parser.cc (right): http://codereview.chromium.org/19539/diff/1/7#newcode3611 Line 3611: new RegExpAssertion(RegExpAssertion::START_OF_LINE)); I'm not sure the extra overhead of unrolling the initial loop is worth avoiding one extra CheckNotAtStart. Unless there is a good reason to optimize "start of line" assertions, I prefer to keep the concepts separate. http://codereview.chromium.org/19539 --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
