Closed nathanmascitelli closed 10 months ago
Hello @nathanmascitelli, this is great! Thank you for this contribution, we'll take a look. You're reporting very intriguing numbers on memory usage, especially for 326 toggles. Would you be able to share a little more information about your feature flags usage/stats?
We'd love to hear more of what you think you can share about your constraints, parameters, and segments usage in your feature flags, average RPS numbers, feature toggle evaluations per request, and also, if you're able to; size of Unleash .NET backup file, maybe in an email?
@daveleek sure, what email can I contact you at?
Hi @nathanmascitelli it's david@getunleash.io
Thanks @daveleek. I did send you an email with the details you asked for.
Description
In looking at our application which uses the dotnet Unleash client we found that a large amount of memory was being allocated by the client when checking if a flag was enabled:
Looking at the callstack it can be seen that these allocations come from creating dictionaries when cloning the provided
UnleashContext
.There are three optimizations that can be made:
Linq.ToDictionary
. Under the hood this will create an empty dictionary and add items to it one by one, causing excess allocations as the dictionary internals grow. Instead create a new dictionary providing the old one as a source, this will create a fresh dictionary with the correct size right off the bat.Properties
inUnleashContext
orBuilder
unless we need to. In all cases we override the empty dictionary anyway so there is no point.Builder
in the hot code path. Its an unnessissary indrection and allocation.My proposed changes address all three points.
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
BenchmarkerDotnet
I tested callingUnleashContext.ApplyStaticFields
before and after my changes, the results: