-
Notifications
You must be signed in to change notification settings - Fork 789
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cache delegates #14582
Comments
I think this would be the way to reduce the allocation: I wonder if there is any other situation besides Action<> and Func<,> family where similar thing is needed, or if this optimization would be targeting them only. |
Might be a good idea to look into caching functions when we can. it's quite big language/compiler feature, please, create a suggestion over at https://github.com/fsharp/fslang-suggestions/issues (or maybe look if there's existing one). Here are some semi-related issuess for reference: |
@T-Gro I think it's mainly Func<> and Action<>, but still might be a good thing to have (ASP.NET APIs come to mind, though I think that JIT can optimize it for us :D) |
C# always cache delegates created in this way, implementation can be taken from here https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA+ABATARgLABQGADAAQY4B0AwhADZ0xgAuAlhAHYDONnYArlFgdmAbkIYAzOSylqpAN6FSK0gAcorAG4BDZjDl9Bw5gBFWLdhx1QAngB4KxADSlWIgHykA+gBMLzKQAvKQcMADuABQAlOIEquTS7oEAsjGkyqpK8QmqGADsPv4slADiMMwA8lAAgr6+kQBEja7ewV7EsZkqAL6EPUA== |
I'm not clear on the details/differences, but note that there are delegates or similar that C# does not cache, as demonstrated in dotnet/runtime#80430. |
Essentially |
* Override `ToString` on `BuildPhase`. * Cache the delegate passed into `ConcurrentDictionary.GetOrAdd` where possible. See dotnet#14582, fsharp/fslang-suggestions#1083, etc.
* Minor compiler perf improvements * Override `ToString` on `BuildPhase`. * Cache the delegate passed into `ConcurrentDictionary.GetOrAdd` where possible. See #14582, fsharp/fslang-suggestions#1083, etc. * Name * Update release notes * Fmt * Remove unneeded `StringBuilder` * Start count at 1 * Go back to `GetOrAdd` * I don't think I fully understand why, but I did some rough microbenchmarking, and for some reason the `GetOrAdd` and `Interlocked.Increment` on a ref cell technique is actually something like twice as fast as `AddOrUpdate`. --------- Co-authored-by: Petr <psfinaki@users.noreply.github.com>
Consider this code:
When memory profiling (using dotMemory, targeting .NET 7), I see that this allocates 1 million
Func<String, Int32>
objects:This is very surprising to me. (Although I'm no expert in esoteric subjects like compiler optimizations, I consider myself a fairly experienced F# developer.)
I propose that F# caches these delegates. (Note: I am unsure if "delegates" is the right term.)
Possibly related: #910, dotnet/runtime#80430
The text was updated successfully, but these errors were encountered: