Closed imathews closed 4 months ago
Thanks for reporting. This is definitely unacceptably slow. I'll see what I can do.
This should now be fixed in 0.22.0 release, where according to my testing the above SQL parses in a few milliseconds:
sqlite x 300 ops/sec ±7.58% (74 runs sampled)
Mean: 0.0033 seconds
mysql x 236 ops/sec ±9.31% (69 runs sampled)
Mean: 0.0042 seconds
bigquery x 345 ops/sec ±1.65% (89 runs sampled)
Mean: 0.0029 seconds
postgresql x 308 ops/sec ±1.60% (86 runs sampled)
Mean: 0.0032 seconds
Feel free to report if you notice any slowness elsewhere. I have mainly been concentrating on feature-completeness, so I suspect there are more areas with lousy performance.
Amazing! Thank you
Hi, and thanks for all the great work on this library! We've recently run into some pretty significant performance issues with complex logical conditions (first observed in
0.17.1
, and still present on the latest0.21.2
release).I'm including the reproducible snippet below, where parsing a single CASE statement takes ~900ms (latest Chrome on an M1 MBP). Converting the statement to a simple logical expression improves performance a bit (~250ms), but is still pretty slow. In the real-world example that this code is derived from, the CASE statement contains ~36 conditions, which leads to a parse time of around 45 seconds.
I've tested this with different dialects, and all show the same results, except for postgres, which continued to spin for well over a minute before I stopped it. Please let me know if there's any additional information that I can provide that would be helpful.