Enable DapperAOT

[mgravell]

• rev Dapper to latest
• enable Dapper.AOT
• enable command caching
• enable strict type mapping
• use explicit column hints

In particular, this avoids a lot of memory churn, due to both the ref-emit Dapper usage and the DbCommand pooling.

Local measurements, before

Type	Allocations	Bytes
| - System.Runtime.CompilerServices.AsyncTaskMethodBuilder<>.AsyncStateMachineBox<>	50,016	10,082,424
| - System.String	46,240	2,617,856
| - Npgsql.NpgsqlConnection	10,022	2,054,458
| - Npgsql.NpgsqlParameter	10,015	1,974,648
| - Npgsql.NpgsqlCommand	10,012	1,628,024
| - Npgsql.NpgsqlParameter[]	20,010	1,307,160
| - Npgsql.NpgsqlBatchCommand	10,012	1,147,538
| - System.Collections.Generic.List<>	30,107	963,424
| - Npgsql.Util.ManualResetValueTaskSource<>	10,001	640,064
| - Dapper.SqlMapper.Identity	10,000	640,000
| - Npgsql.NpgsqlParameterCollection	10,007	480,736
| - Npgsql.NpgsqlBatchCommand[1]	10,000	320,000
| - System.Int32	10,177	244,444
| - <AnonymousType{Id}><System.Int32>	10,000	240,000
| - Dapper.SqlMapper.<>c__DisplayClass174_0	10,000	240,000

after (same workload):

Type	Allocations	Bytes
| - System.Runtime.CompilerServices.AsyncTaskMethodBuilder<>.AsyncStateMachineBox<>	60,017	11,282,552
| - System.String	46,220	2,617,506
| - Npgsql.NpgsqlConnection	10,021	2,055,622
| - Dapper.Internal.AsyncQueryState	10,006	667,176
| - System.Int32	10,167	244,008

The string allocations here are presumably somewhere in the core of Npgsql - columns or other metadata; removing this would require digging. It isn't strictly required, as Dapper.AOT with this setup does not query any names / string-values.

There is some additional work we could perhaps do to use NpgsqlCommandParameter<T> to avoid the boxed System.Int32; this would requires some Dapper.AOT tweaks.

[DeagleGross]

do we want to have both DapperAOT and Dapper variants? Aren't we losing "plain" Dapper testing here?

[mgravell]

I didn't want to double everything, and I don't think we need to retain both - the key thing here is "what approach would the user be using?", and DapperAOT === Dapper from that angle.

[mgravell]

crank results, sadly, have been somewhat underwhelming, with the performance staying more or less unchanged; marginally faster, but in the 3rd digit, so: not worth discussing.

But whelmed or not, it is in the right direction and improves the tech stack - we could if we wanted try running those in AOT mode, for example.

Perhaps more importantly, we've identified a few more places where the bottleneck isn't. I have some ideas there, relating to the (optional, disabled) multiplexed npgsql core, and how that could be improved to achieve the results that are currently lacking.

[mgravell]

To explain the changes a bit more, let's take this example:

+ [DapperAot, CacheCommand, StrictTypes, QueryColumns("id", "message")]

• [DapperAot] simply enables the interceptor generator for this scope; this means that rather than doing runtime type inspection and ref-emit, we emit interceptors that perform the same query directly; this removes some significant "first time per query" expensive CPU work and allocations (reflection , etc), and "every time" lookups (CPU) against the cached set of such mechanisms; it also enables some new features (below) that are too complicated to try to retro-fit into the older Dapper code (which is mostly ILGenerator, with the brittleness you'd expect from that)
• [CacheCommand] enables per-usage caching of DbCommand instances, so before creating a new DbCommand, it'll check a concurrency-aware store for a recently used command doing the same thing, update the parameter values, and use that against the current connection; this can lead to significant allocation reductions, especially on Npgsql which has a command rewrite step that can survive this usage
• [StrictTypes] means that instead of trying to be wildly forgiving (i.e. checking the inbound data types: if it is an exact match, use the type-specialized methods like GetInt32 - otherwise use GetValue and possibly things like Convert.ToInt32); we optimize for performance and assume the types match - i.e. it just uses GetInt32 directly - this is a CPU saving (but that saving is relatively small compared to query latency)
• [QueryColumns] pre-defines the expected column bindings; instead of checking the inbound column names and comparing them to what it knows about (after normalization), it does all that work at build-time and just emits "the first column goes to the Id member, the second column goes to the Message member; that's it" - this is a CPU saving (but that saving is relatively small compared to query latency)
• the combination of [StrictTypes] and [QueryColumns] allows all data metadata checks to be skipped entirely, which can potentially save both CPU and allocations