Support trimming and AOT about pidgin HOT 5 CLOSED

To the extent that it's possible I wanna support trimming/AOT. For context I simply haven't tried them, they're new(ish) features and the library was written before they existed. I'm certainly not philosophically against it or anything like that - just never tried it before. You're the first person to have asked me about it.

These error messages all come from runtime codegen parts of the codebase (unsurprising since runtime codegen is not supported in AOT obviously). But the runtime codegen is there only as a microoptimisation (devirtualising generic code) and I think it's likely that performance would be acceptable for most users without the microoptimisation. The fallback code isn't super reflection heavy or anything like that, it just has some interface calls in loops. (I know that there've been some devirtualisation improvements in the jit in recent years so I wonder whether I even need this codegen any more.)

So ideally I'd be able simply to disable those code paths (at runtime?) and just use the existing fallback implementation if we're in a trimming/AOT scenario.

I had a skim through the docs and it doesn't seem like there's an obvious way to do that, at least nothing jumped off the page at me. Sounds like you know more about this than I do - is there a way for a lib to detect whether it's being deployed trimmed/AOT? Something in RuntimeHelpers perhaps?

I'm also open to multi-targeting the library, as long as Nuget/PackageReference can do asset selection for AOT. I don't want to publish two different packages.

from pidgin.

Happily it seems like the runtime codegen bits are no longer needed with recent jits. I looked at the asm from a current (net7) runtime and it seems like Comparer.Default/EqualityComparer.Default got devirtualised+inlined just fine. So I just deleted the code with the warnings.

Fixed in 6342656 and shipped in v3.2.2.

Thanks for bringing this to my attention!

from pidgin.

I don't know why the AOT compiler spins. Sounds like it could be a bug in the AOT system.

from pidgin.

I'm not experienced with AOT. This was my first real exploration attempt.

So ideally I'd be able simply to disable those code paths (at runtime?) and just use the existing fallback implementation if we're in a trimming/AOT scenario.

It seems possible using RuntimeHelpers.IsDynamicCodeSupported with .NET 5 (check bottom example). However, the suppression attribute (RequiresDynamicCodeAttribute) is .NET 7+. As an aside, the <IsAotCompatible>true</IsAotCompatible> csproj property is .NET 8.

I don't know why the AOT compiler spins. Sounds like it could be a bug in the AOT system.

I think so too, but I would need to install and check .NET 8 preview as it may have been fixed already.

from pidgin.

Thanks!

from pidgin.