From trace when we open a .Net Core solution, we noticed that more than 10% virtual allocation was triggered by creating the StringBuilder in Microsoft.Build.InteringBinaryReader.ReadString()
It appears a part of msbuild code has already tried to share stringBuffer. Can we do the same thing here? It could reduce GC press in the design time build phase right after loading a solution.
If we count the phase right after loading solution, this code path contributes 26.8% of virtual allocations. Although the memory allocation is temporary, it adds lot of GC pressure during that phase.
From trace when we open a .Net Core solution, we noticed that more than 10% virtual allocation was triggered by creating the StringBuilder in Microsoft.Build.InteringBinaryReader.ReadString()
It appears a part of msbuild code has already tried to share stringBuffer. Can we do the same thing here? It could reduce GC press in the design time build phase right after loading a solution.
If we count the phase right after loading solution, this code path contributes 26.8% of virtual allocations. Although the memory allocation is temporary, it adds lot of GC pressure during that phase.