Feature: Move to DapperAOT?

[jeroenhabets]

Hi,

Have you ever considered moving to DapperAOT? I would imagine (most of) Hangfire.PostgreSql's queries to be known at build time so this could be a performance boost (incl. prevent GC for Strings etc.)? Or do you consider DapperAOT to not be mature or popular enough? Or are there critical features not supported by DapperAOT?

If possible DapperAOT could potentially contribute to quite a few of the performance improvement suggestions over the years.
If not, "No" is a completely acceptable answer 😃 .

Regards, Jeroen

[azygis]

As simple as "I'm not using it personally so I've no idea how's it better or worse". If anyone is up for it, PR is welcome.

I'd rather use regular ADO.NET just because of positional parameter queries (which avoids any string manipulation), sadly those are not supported with Dapper (no idea about DapperAOT, whether it supports that or not).

[latop2604]

PR added.

Some caveats:

• QueryMultiple is not supported and will continue to use the not AOT version.
• tuple-type not supported (yet)
• Has to use Linq in CreateExpiredJob instead of foreach to preserver anonymous type info.

It is possible to apply the attribute globally using [assembly:DapperAot]. I chose to be a bit more explicit instead. Dapper.AOT will generate a warning on dapper method if the attribute is not explicitly set (enabled or disabled).

[jeroenhabets]

Wow! Thanks @latop2604! Curious to learn: Did you notice any performance improvements?

FYI only:

• QueryMultiple is not supported and will continue to use the not AOT version.

Linking DapperAOT issue calling for QueryMultiple/QueryMultipleAsync support.

[latop2604]

I only ran the unit test. Not hangfire itself. But I personally use dapper.aot since months/years.

For perf I don't think it will bring improvement except for cold start.

It's also a step forward to native AOT support / trimming. But some piece of code still need to be changed like json serialization or hangfire itself