Cache TableRecord Constructor in TableImpl for use in Tools.recordFactory()

[lukaseder]

Currently, when creating TableRecord in result queries, the record is instanciated using reflection, which allows for creating records from private constructors, too.

However, this constructor is looked up every single time, instead of it being cached:

final Constructor<R> constructor = Reflect.accessible(type.getDeclaredConstructor());

In a profiling session running 1M queries, this accounts for 0.85% of the samples, so it's definitely worth optimising:

[lukaseder]

This may as well have been a safepoint artifact from the profiling session. I've never noticed this again since.

[lukaseder]

This did show up again in another profiling session, as one of the primary allocation problems:

A quick test reverting type.getDeclaredConstructor().newInstance() to type.newInstance() (deprecated, but cached) yielded promising results. I'll investigate this again.

[lukaseder]

Ah, the difference is that in the original screenshot, the recordFactory() call was done per-cursor, which isn't really worth caching.

But now we're looking into a benchmark where Result.into(Table) is called, and that possibly multiple times. Or even users looping over Result and calling Record.into(Table) on individual records.

Perhaps, a generated TableImpl could have a cached reference to its generated TableRecord constructor, if available.

[lukaseder]

I've tried caching the Constructor in the Configuration, but that's slower than the status quo.

[lukaseder]

Attaching the cached Constructor to TableImpl (i.e. the generated tables) produces good results:

Before

BenchmarkRecordMapper.intoTableCache          thrpt    7  3134634.762 ┬▒  55709.662  ops/s
BenchmarkRecordMapper.intoTableNoCache        thrpt    7  3126145.774 ┬▒ 105931.506  ops/s

After

BenchmarkRecordMapper.intoTableCache          thrpt    7  3369384.579 ┬▒ 39552.058  ops/s
BenchmarkRecordMapper.intoTableNoCache        thrpt    7  3378989.655 ┬▒ 54101.392  ops/s

Roughly 5% better on Result.into(Table) calls is definitely worth it as this also affects all kinds of Result.intoGroups(Table, Table) and other similar usages. CursorImpl will also profit, but only marginally, because it looks up the constructor only once per CursorImpl.

[lukaseder]

In fact, this improves any usage of DSLContext.newRecord(Table) and related usages where a Table is available to construct a TableRecord

[lukaseder]

Fixed in versions:

• 3.20.0
• 3.19.4 (Cache TableRecord Constructor in TableImpl for use in Tools.recordFactory() - Merge [#6639] #16250)
• 3.18.11 (Cache TableRecord Constructor in TableImpl for use in Tools.recordFactory() - Merge [#6639] #16251)
• 3.17.20 (Cache TableRecord Constructor in TableImpl for use in Tools.recordFactory() - Merge [#6639] #16252)