perf: keyword lookups in the tokenizer

[vmg]

Description

Happy Thursday everyone, this week we're bringing sqlparser performance improvements. I had a chance to sit with @frouioui and look at some of the profiles that we're now acquiring from his Are We Fast Yet (TM) work. There was nothing glaringly obvious that would provide massive optimization gains (as one would expect at this point, Vitess is quite optimized already), but for the normal request lifecycle, all of the sqlparser operations on the AST are always quite hot, and most importantly for our goals, CPU-bound.

Let's start squeezing some blood out of this stone: this particular PR comes from allocation benchmarks: the code in our SQL Tokenizer that processes SQL keywords allocates so much memory that it's showing as a hotspot in a CPU profiler and very clearly an allocation hotstop in the memory profiler.

Why does it do all these allocations? Well, right now it is copying the current token it's processing into a temporary buffer (this is the buffer that gets returned to the caller) and then it does yet another copy of the buffer to lowercase it so it can be looked up in our keywords table (people following at home will surely remember that SQL keywords are case insensitive).

Let's improve this with some very classical Compiler Theory approaches: Instead of using a hash table to lookup keywords, use a perfect table (a perfect table is a minimal hash table where lookups cannot collide -- it is measurably faster than a normal hashtable, even the one built-in in the Go runtime). And since we now have a perfect hash table, we control the hashing algorithm used for lookups... So we can switch the algorithm to perform the hashing case-insensitively. This makes it so we don't have to create lowercase copies of all keywords!

name                     old time/op  new time/op  delta
Normalize-16             7.50µs ± 2%  7.38µs ± 1%    ~     (p=0.222 n=5+5)
ParseDjango-16           11.4µs ± 2%  11.0µs ± 2%  -3.69%  (p=0.016 n=5+5)
Parse1-16                14.5µs ± 2%  14.2µs ± 2%  -2.08%  (p=0.032 n=5+5)
Parse2-16                46.9µs ± 3%  44.5µs ± 3%  -5.07%  (p=0.008 n=5+5)
Parse2Parallel-16        9.29µs ± 4%  9.13µs ± 3%    ~     (p=0.548 n=5+5)
Parse3-16                5.82ms ± 1%  5.85ms ± 1%    ~     (p=0.222 n=5+5)

Results are :gucci: in the most realistic parse benchmarks. The pathological benchmarks do not regress.

Related Issue(s)

Checklist

• Should this PR be backported?
• Tests were added or are not required
• Documentation was added or is not required

Deployment Notes

Impacted Areas in Vitess

Components that this PR will affect:

• Query Serving
• VReplication
• Cluster Management
• Build/CI
• VTAdmin

[shlomi-noach]

I'm loving this.

[harshit-gangal]

nit: use require over t.fatal

[harshit-gangal]

nit: use require.NoError(t, err)

[harshit-gangal]

nit: use require.NoError(t, err)

[harshit-gangal]

nit: use require.NoError(t, err)

[harshit-gangal]

same as above.

[harshit-gangal]

same as above.

[derekperkins]

I love how entertaining AND descriptive your PRs are @vmg :)

[GuptaManan100]

💯

[vmg]

@harshit-gangal: I've added testify to all the new test cases, but I haven't updated the benchmarks to use testify because the require.NoError check actually adds measurable overhead and screws with the measures (:sweat:).

Ready to merge. 👌

[deepthi]

@harshit-gangal: I've added testify to all the new test cases, but I haven't updated the benchmarks to use testify because the require.NoError check actually adds measurable overhead and screws with the measures ().

What about quicktest? Does it add overhead?

[vmg]

@deepthi I haven't tested it, I just noticed the testify issue when re-running the benchmarks. I don't think it's particularly worrisome, Testify still works great for normal testing, so we can fall back to a simple if err != nil in the very few places where we have tight loops in benchmarks.