c# - Why the "View Heap" result does not match with 'Process Memory Usage' in Visual Studio -


i trying use visual studio track memory usage in app. in 'diagnostic tools' window, shows app using 423 mb. thank go 'memory usage' , 'viewheap', when click on snapshot, table of size of objects.

enter image description here

but when add number up: = 3317228 +403764+354832+264984+244836+195748+144032+28840+16452+13920+13888+3428+2100+20 = 5004072 = 4.77 mb

my question why number 4.77mb not match 423mb see on "memory" chart. expect see table on left breakdown of 423 mb went. please tell me missing?

why view heap size not match memory chart size?

there dozens of potential reasons this, including jitter, debug tools, debug symbols, just code, garbage collection et al. we'll go through 2 of big ones.

just code

the just code feature of visual studio tends hide allocations, exceptions, breakpoints, , other non-code meta-data user, not loaded .pdb file or open project. see msdn code details.

debugging symbols , tools

when debugging any project in visual studio, visual studio debugger runs , allocates memory allow breakpoints, exception catching, , other features. true diagnostic tools capture, should use alt+f2 option, or debug > start diagnostic tools without debugging.... you'll want switch release mode portion. step alone cut memory graph showed (for me) 21.5mib 5.5mib, indicating debugging symbols , debugging tools substantial factor. remember, in order visual studio able catch exceptions, breakpoints , other data, must attach process, , objects within process.

so, how make these numbers match?

you shouldn't worry numbers matching. purpose of memory graph , view heap chart allow see spikes , odd memory fluctuations, indicate programme incorrectness. should looking those, rather focusing on difference between 2 values.

that said, there steps can take accurate results.

truly matching numbers

if truly want match them, don't think can done in manner wish. can, however, closer. first step start diagnostic tools without debugging..., select memory usage. once selected, click settings gear next it, , make sure profiler type mixed (managed , native). then, click start , take snapshots can examine memory use. once done so, stop debugging , examine memory.

to examine memory, click top-left blue number in snapshot box snapshot wish examine. on page, click grid icon on top-right , deselect both just code , collapse small objects. switch native heap tab , same, deselecting just code , select include freed allocations.

you should find alone brings error closer actual value. (the actual value being private bytes , error being heap size) application tested on, brought total (from both heaps) 1.0265mib, same allocation indicated task manager when ran programme outside of visual studio (this actual value 1.1211mib, numbers small margin of error expected).

what include freed allocations mean? essentially, when gc clears memory, memory not removed space of application. instead freed use other objects, can still remain application. garbage collection complicated topic, , beyond scope of question , answer.

additional notes

memory allocation, usage , measurement very complex topic. unfortunately, there not many 100% fool-proof ways handle situations this, , more fool-proof , accurate solution is, more complex, slow , difficult use is.

references

msdn code: https://msdn.microsoft.com/en-us/library/dn457346.aspx#bkmk__net_framework_just_my_code

msdn garbage collection: https://msdn.microsoft.com/en-us/library/0xy59wtx%28v=vs.110%29.aspx

the rest of answer based on my own experimentation , trial , error, , subject potential inaccuracies may result of different environments. steps presented herein may not work developers, , performed visual studio 2015 rc version 14.0.22823.1 d14rel.


Comments

Popular posts from this blog

python - TypeError: start must be a integer -

c# - DevExpress RepositoryItemComboBox BackColor property ignored -

django - Creating multiple model instances in DRF3 -