Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
High Value Of Private Bytes Metric #5654
I'm using some simple C# code on .NET Core to look at how Azure Functions perform. The use case is quite simple: add 10 million int values to an ArrayList as part of an Azure Function, and use a time trigger set to 1 minute to invoke the function. (I know the ArrayList is obsolete and not to be used anymore, but I'm just employing it to get a significant chunk of space allocated on the heap)
Therefore the C# code is this:
For an ArrayList, each boxed int occupies 12 bytes, due to the type object pointer (aka method table address – 4 bytes), the value stored (an int, which takes 4 bytes on either x86/x64) and the sync block index (4 bytes). All these scattered boxed ints total 114.45 MB (12 bytes/object x 10 mil objects). On top of this we have the internal arrays themselves that get allocated in turn, and which take 128 MB (16 bytes + 32 bytes + 64 bytes + … + 32 MB + 64 MB). The total comes up to 242.45 MB. The value can be confirmed by running a similar test method against BenchmarkDotNet.
There's no much else being allocated on the heap aside the value summed above.
Running VMMap against this code (compiled for .NET Framework) shows the private bytes as close to the expected value (I'm assuming one of the GCs gets a chance to free up some of the allocated data up until 242 MB):
But looking at the performance of the Azure Function, either Function App's "private bytes" or the App Insights' "process private bytes" have considerable higher values (which actually come closer to the overall virtual memory usage as seen in VMMap before):
As the private bytes go into the cost of the Azure Functions, it's of interest to understand why the value observed is much higher than one would expect it to be. I've expanded on the context of the issue here.
There are a few more aspects I've been reviewing:
I've also looked at the assemblies loaded in the AppDomain by the .NET Core local app and the Azure Function respectively, using
For the .NET Core local app there’s a minimum number of assemblies loaded (code output is here) , just as expected, but for the Azure Function one there’s literally a ton (output is here). Judging by the fact that the code one types in the Azure Function actually makes it as an assembly in itself most likely (