[Perf] Make library AOT-compatible

[alexandrehtrb]

Hello,

It would be interesting to make this library AOT-compatible, for performance benefits.

https://devblogs.microsoft.com/dotnet/creating-aot-compatible-libraries/

Also adding .NET 9 as a target framework.

I tested AOT compatibility on this repo and on FSharpAux repo, both seem to be OK.

In this repo, FSharp.Status seems to not use anymore OptimizedPriorityQueue package, maybe it could be removed from the fsproj.

[bvenn]

Thanks for reporting @alexandrehtrb
It seems the PriorityQueue is used in https://github.com/zieglerSe/FSharp.Stats/blob/9cc43ef84b692ed0d68181d7e224036ddfb76335/src/FSharp.Stats/ML/Unsupervised/HierarchicalClustering.fs#L5.

@kMutagene, do you have insights regarding the AOT-compatibility

[kMutagene]

@kMutagene, do you have insights regarding the AOT-compatibility

Well it seems from the linked article that we can only know if its fine if roslyn analyzers do not throw warnings or we do not get warnings when compiling to AOT. Not sure if the first option will work for F# as F# has its own compiler and does not use roslyn. The second looks like much manual work to me.

TLDR;: only if we can do automated testing for AOT compilation

However, i agree that we might target a newer .net version (although i'd always go for LTS), i think some of the changes that @muehlhaus is working on need .net 8 anyways

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for raising this! Here's a concrete analysis of the AOT compatibility situation and a proposed path forward.

Current blockers

1. OptimizedPriorityQueue (v5.1.0) — still actively used in HierarchicalClustering.fs via FastPriorityQueue<T> and FastPriorityQueueNode. This is a pre-generics inheritance-based pattern from an old library. .NET 6+ ships a built-in System.Collections.Generic.PriorityQueue<TElement, TPriority> that is AOT-compatible and requires no inheritance. Replacing this is the clearest path forward for the main FSharp.Stats package.

2. FSharp.Stats.Interactive uses F# reflection for pretty-printer registration and is inherently AOT-incompatible — but that's expected for an interactive tooling package and can stay as-is.

3. The open Microsoft.FSharp.Reflection in Ops.fs is benign — the block only uses NoDynamicInvocationAttribute from FSharp.Core, not dynamic reflection.

Automated AOT testing

@kMutagene's concern about automated testing is valid. Here's the practical approach for F#:

• Add <IsAotCompatible>true</IsAotCompatible> to FSharp.Stats.fsproj — this causes the F# and C# compilers to emit AOT warnings via the built-in Roslyn/FSharp analyzers on any AOT-incompatible pattern.
• For a fully automated smoke test, add a minimal console test project targeting net8.0 (or net9.0) with <PublishAot>true</PublishAot> and run dotnet publish -r linux-x64 in CI — this will fail at link time if any AOT-incompatible code is reachable.

Suggested scope

Given the above, the minimal change to make FSharp.Stats (the core library) AOT-compatible would be:

1. Replace OptimizedPriorityQueue with System.Collections.Generic.PriorityQueue in HierarchicalClustering.fs (requires bumping the TFM to net6.0 or later, or conditional compilation for multi-targeting)
2. Add <IsAotCompatible>true</IsAotCompatible> and verify no new warnings appear
3. Optionally add a CI AOT publish step

Happy to draft a PR for the PriorityQueue migration if that's the agreed direction.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@7ee2b60744abf71b985bead4599640f165edcd93