Open sidorares opened 1 year ago
I think I'd prefer refactoring code back to reading packet directly in a generated row constructor and not calling the constructor with all fields passed as list of arguments
Benchmarking "select 1000 rows, each row has 1 to 1000 INT columns", y axis is "columns X 1000 per millisecond", the higher the better
Family of 3 graphs is mysql2@2.3.0, family below is current 3.4
Interestingly the difference is more noticeable on a single cpu box ( benchmarked is a hobby railway.app server -> free planetscale database ). When I test on my local laptop the difference is less prominent BUT cpu consumption for node process is 300-400%. My theory: V8 optimiser runs in a separate thread(s) and if there is enough room does not affect main JS thread much
I'll add a benchmark later with "interpreting" parser, e.i the one that does not have "generate a parser js code and eval it upfront" pass
Top graph ( best performance ) - mysql2@2.30 Middle - current Bottom, "static / interpreting parser" from #2099 branch. I was hoping to see an intersection and switch to a "static" parser when response contains large number of columns but it looks like current version performs better across the line ( and 2.3.0 performs even better )
@testn we did have some initial discussion when the original change was made in #1402 but wanted to review and benchmark again. I think the fix should be simple, if the performance numbers are visible enough worth adding.
A bit of context: previously, generated parser class was used to create an instance of row object. V8 caches access to fields, so in theory doing
is much faster then
We could potentially generate some proxy
RowConstructor
class that assigns all fields from passed from the constructor. For example, currently generated code forconnection.query("show tables)
iswe could make it something like that?
Simple benchmark shows 50-60x time difference in row construction, not sure how big the penalty is in the total mix but might be still visible ( constructing an object with 7 fields 10m times and then accessing all fields )
parse1 runs approx 1600ms while parse2 approx 30ms