Template parsing performance degradation between 0.8.3.3 and 0.9.1.1

[ugenl]

Hi again all, back with another enormous template string and a related performance issue.

Much like the previous issue (#310), I'm using 0.8.3.3 as the previous baseline, and using the same test.

The difference here is the template string that I've attached, which is effectively one giant assign block with a ton of lookups and comparisons that are linked together by ors and ands.

Benchmarks (averaged over 100 runs):
0.8.3.3 - 0.0155 seconds
0.9.1.1 - 1.819 seconds

Also for a bit of additional information, when checking the profiler, I see very long chains (> 300) of LiquidParser.expr calls.

test_string.txt

[msangel]

I don't know whats in that file but my text editor hangs on opening it attempts...

[msangel]

Oh

[ugenl]

yeah, it's...massive. The file that held the original whole string (before anonymization and paring down) was ~2.7 MB 😬

[msangel]

Navigating it with VIM works better then in xfce mousepad.
And it is entire expression, so not wonder LiquidParser.expr called here. Still not clear degradation reason.
With high probability will need help of @bkiers

[msangel]

@ugenl in some of these changes new flavor was added. Could you please tell what flavor is used to parse this?
Not sure if this is important, but there definitely was some related with this changes.

[bkiers]

Navigating it with VIM works better then in xfce mousepad. And it is entire expression, so not wonder LiquidParser.expr called here. Still not clear degradation reason. With high probability will need help of @bkiers

I will have a look at this 👍

[ugenl]

@ugenl in some of these changes new flavor was added. Could you please tell what flavor is used to parse this? Not sure if this is important, but there definitely was some related with this changes.

@msangel It doesn't look like we're changing flavors, so I believe we should be using the default Flavor.LIQP flavor.

[bkiers]

Apologies, I've not found the time yet. I've been busy with work. Hopefully this weekend.

[vtatai]

AFAICT from doing a bisect seems like the issue is still with the same commit as last time - I know it was fixed, but perhaps this is a more extreme scenario (?).