use global regexes (cached) for small speed improvement

[lukeapage]

I wonder if this will help with speed given how much we use regex's

http://jsperf.com/regex-caching-lp

[seven-phases-max]

(I added a few browsers there) Curiously it looks like it's dramatically faster only in Chrome :). I guess it's still could be a neat piece of code to use for those regexps that execute the most (e.g. vars, properties till : etc). But it does not look like a solution for those #2339 things.

[rjgotten]

Curiosly it looks like it's dramatically faster only in Chrome :)

V8 likely implements regex literals strictly per ECMAScript 5, which states that regex literals are compiled each time the literal is evaluated, as if it had been declared using the new RegExp(pattern, flags) syntax.

The other engines are probably still implementing the ECMAScript 3 behavior, which states that regex literals are compiled once, before the containing program or function is compiled and executed, and any use of the corresponding literal is treated as a reference to the same compiled object.

Or they're using a hybrid form, where the regex state machine is compiled and created only once, but fresh instances of new RegExp are created around it each time the literal is encountered.

[jonschlinkert]

V8 likely implements regex literals strictly per ECMAScript 5, which states that regex literals are compiled each time the literal is evaluated

You should see what caching can do when the regex is dynamically created from a string based on options or user input etc. For example:

var cache = {};
function createRegex(str) {
  return cache[str] || (cache[str] = new RegExp('foo' + str + 'bar'));
}

I created this not long ago. Really, the code above is all that's needed if the only input is a string, still it's pretty interesting how much of a difference caching can make

[matthew-dean]

If you look at parsers like acorn (http://marijnhaverbeke.nl/acorn/), and a few others that have reputation for speed, you'll notice that there are barely any regexes at all, and instead use sequences of OR || statements, and often check individual characters against numerical character codes. The code ends up being more verbose, but from what I've read, JS engines can optimize the crap out of very linear logic statements and static functions. Regexes are more of a mixed bag, and things like backtracking in regex can be expensive.

In Less, we often have a series of OR checks for regexes, and those regexes themselves have backtracking OR switches. Pragmatically, it's easy to maintain, but that pattern is more likely to negatively impact performance.

I've been thinking about how we can very gradually improve speed of individual node matching. I was reading this - https://github.com/felixge/faster-than-c (a very good read about making JS faster than C), and he advocates benchmark-driven development. I was wondering if we could create some kind of test harness, like our own kind of JSperf, that has sequences of .less input, and tests the performance of matching to a single matching function in the Less library (and verifies that the output is as expected). Then a dev could tweak that function, run more tests, save / graph the results.

That way we don't have to KNOW what would be faster so much as try something and see if it's faster. If it's faster on all supported platforms, make a PR for that particular function, badda bing, badda boom.

I'm not sure the best way to go about that, but it would be great to be able to quickly test all these great ideas.

[matthew-dean]

Also, would there be any value at looking at JS-based CSS parsers like https://github.com/css/gonzales to see if there are ideas we could port? Surely there would be relevant pattern matching from something like that. I know each of our entities gets a lot more complex, but just an idea.

[rjgotten]

If you look at parsers like acorn (http://marijnhaverbeke.nl/acorn/), and a few others that have reputation for speed, you'll notice that there are barely any regexes at all, and instead use sequences of OR || statements, and often check individual characters against numerical character codes.

That type of parser formally separates itself into a lexer/tokenizer and a LALR(k) parser. The power and speed of that approach comes from employing generalized regular expression matches on a very small scale (mostly for recognizing identifiers, filtering whitespace, etc.) and limiting yourself to a fixed set of hand-coded lookaheads by hand-writing a parser based on accepting the lexer's tokens via a set of production rules formulated as a BNF grammar.

You could do that with Less as well, but you'd need to build on a compliant CSS parser first, which can tokenize and parse CSS selectors, which (if I understood correctly from the original discussion) is really where regex lookahead starts to hurt a lot.

I remember CSS 2.1 having a BNF grammar for the language in the W3C recommendation. I assume CSS 3 is no different and does the same. You could still short-circuit a lot of the grammar, since you don't need to know every little detail of it.

[matthew-dean]

@rjgotten Is this what you meant? http://dev.w3.org/csswg/css-syntax/

They really break it down. Just came across that recently.

[lukeapage]

I looked briefly at switching to a parser generator - basically its a rewrite. Id love to use a parser generator to make it all generated.

[matthew-dean]

I've read that parser generators can leave you with a different set of problems (advocating hand-writing parsing), but I don't really know one way or the other. I think as long as we can benchmark the results, however we got there is all good.

[lukeapage]

Can you run this through on a few browsers?

http://jsperf.com/regex-string-size

I'd expect if size of the string is less's performance problem (as shown by chunkInput) I'd expect to see the speed decreasing with size of the string. Any idea what wrong with the test if that isn't happen? Got to run for a flight or I'd have done more testing...

[matthew-dean]

On my setup, Safari performed best, with all the non-cached operations happening at roughly the same rate, and the cached operations at a different rate. Chrome 41 shows performance issues as the string size increases. Chrome 42 does not show as much issue. Firefox trails way in last with every operation performing the same rate, cached or not.

I think we can expect that every JS engine will optimize each regex differently, and even the same regex will perform differently with each input. So, nothing will beat testing.

I did another arbitrary test here (http://jsperf.com/regex-string-size/2) , just comparing OR in regex vs. testing two regexes and matching one or the other. I also changed up where the backtracking happens in the regex. And the browsers don't all change performance at the same rate. In fact, Firefox does better at an OR between two regexes than one of the regexes which backtracks in a different place, while Chrome and Safari always do much better at a single regex.

At the very least, the data shows caching is generally better than not caching, except Firefox. But then, it's certainly not worse.

I think we can start with what @jonschlinkert said. For any place in the code where we're testing against multiple regexes, it should still be faster to dynamically create a regex and test against a single one. And even faster if the regex isn't being redefined every time the function is visited. (Implement caching). And then run benchmarks on changed functions.

[lukeapage]

Cached vs non-cached seems to indicate regex setup cost does not increase with regex complexity so it might be a small win. I tried adding a few current character checks to avoid running the regexes used the most. Will post back here next time i work on it...

[seven-phases-max]

I'd expect if size of the string is less's performance problem (as shown by chunkInput)

I think it's not just the size of the input string but the "the size + some lookahead regexs". I.e. only certain re patterns timings may increase exponentially as the input size grow and chunkInput just makes those to bail out earlier.
So to get the real picture a test needs to involve one of those "bad" regexs (usually those with ?----+/*) and the input string also needs to be not not-ambiguous for that particular pattern. Simple patterns (like this .mixin one above) find their match in the input immediately hence the input size does not affect too much.

P.S. (a bit offtopic) When making the highlighter I found this tool to be quite useful for debugging of such "bad" patterns (it really helps to detect some problematic parts earlier though you still need to invent/predict those ambiguous inputs that may put the regex down yourself (so it's still kinda tedious thing)).

[matthew-dean]

you still need to invent/predict those ambiguous inputs that may put the regex down yourself (so it's still kinda tedious thing)

I agree, it's a ton of work to try to predict what will work. That's why it would be great if we could staple a benchmarker integrated to the Less lib directly (only loaded for tests / development). Change code, and if the results are accurate, and it's faster, keep code. If we could turn on the benchmarks just for function X and run all the less tests (which would throw a bunch of .less patterns and file sizes, yes?), it seems like it would give a more "real-world" picture.

[matthew-dean]

@seven-phases-max The highlighter and other tools are cool too, definitely should check those out. Let's hit this from all sides. Maybe we could make "performance" the next major feature (other than features in progress)?