Interpret CLR Profiler results question
- Hi,
I'm new to the CLR Profiler. When I generate 20 instances of a form while running the CLR Profiler I get the following results:
Allocated bytes: 20 instances of the form
Final heap bytes: 12 instances of the form
Objects finalized: 19 instances of the form
I would expect that an instance of the form is either in the final heap or finalized, so those numbers should count up to 20 and not 31. On the other hand, if there are indeed 31 instances (due to bad programming ;-o ), then I would expect that there are 31 instances allocated instead of 20.
Can someone help me interpret those numbers?
Thanks!- Changed TypeeryangMSFT, ModeratorWednesday, November 18, 2009 7:41 AMno response.
All Replies
- Hi,
The document shipped with the package has a very detail description about the CLR Profiler, it's worth to read.
Here are some segments from the document:
Allocated bytes is simply the sum of the sizes of all the objects the program allocated. This also includes some objects the CLR allocated on behalf of the program.
Final Heap bytes is the sum of the sizes of all the objects in the garbage collected heap at the end of the program run. This may include some objects that are no longer referenced, but that have not yet been cleaned up by the garbage collector.
Objects finalized is simply the number of objects that were finalized, i.e. whose finalizer actually ran. This is as opposed to the object being cleaned up by calling its Dispose method explicitly or as part of a C# using statement.
Thanks,
Eric
Please remember to mark helpful replies as answers and unmark them if they provide no help. - Hi Eric,
Thanks for your reply!
I read the document, but I just don't see how I can get the results that I mentioned in my previous post. The 'Allocated bytes' and 'Final Heap bytes' give also the number of objects. It seems to me that an object is either in the 'Final Heap' or belongs to the 'Objects finalized'. I also expect that all objects, in whatever way created, are taken into account in the 'Allocated bytes' group. So I would conclude that, looking to the number of instances of a specific object, the number of instances mentioned in 'Allocated bytes' can never be smaller then the sum of the number of instances mentioned in 'Final Heap bytes' and 'Objects finalized'. But this conclusion is in contradiction with the results in my previous post...
So if you've any idea what's wrong in the above reasoning, it's very welcome!
Thanks again! - Hi,
You're right, all objects are taken into account of 'Allocated bytes', but, beside 'Final Heap' and 'objects finalized', an object can also locate in 'objects that has no finalizer, and has been GCed ', so, we have something like this:
'Allocated bytes ' = 'Final Heap bytes ' + size of 'Objects finalized ' + size of 'no-finalizer objects that has been GCed '.
From CLR Profiler, I can only get following data:
Allocated bytes: 611,488
Final Heap bytes: 119,461
Objects finalized: 1
the first two values are in bytes , but, from your data, the first two vlaue seems are the objects' count , did you calculate them by yourself? what's the raw data you got from CLR Profiler?
Thanks,
Eric
Please remember to mark helpful replies as answers and unmark them if they provide no help. - Hi Eric,
I got the number of objects by clicking on the histogram button. Then all the objects are listed in the right pane. For each of the objects the number of instances is mentioned amongst others, e.g.:
(3'984 bytes, 0.33% - 12 instances, 332 bytes average size)
Thanks,
Marc - Hi,
so, how about the value of Allocated bytes and Final Heap Bytes on the summary panel, select Edit -> Copy, and paste those data here.
Thanks,
Eric
Please remember to mark helpful replies as answers and unmark them if they provide no help. Hi Eric,
After running the tool again, this is the complete summary:
Allocated bytes: 2'086'758
Relocated bytes: 20'866
Final Heap bytes: 1'223'374
Objects finalized: 1'076
Critical objects finalized: 0
Gen 0 collections: 5
Gen 1 collections: 2
Gen 2 collections: 1
Induced collections: 0
Gen 0 Heap bytes: 2'350'172
Gen 1 Heap bytes: 1'603'548
Gen 2 Heap bytes: 311'892
Large Object Heap bytes: 1'276'928
Handles created: 5'909
Handles destroyed: 3'228
Handles surviving: 2'681
Heap Dumps: 0
Comments: 0
And when clicking 'Histogram' for the different items, the following data can be found concerning the instances of a specific form:
- Allocated: 6'640 bytes, 0.32% - 20 instances, 332 bytes average size
- Relocated: 332 bytes, 1.59% - 1 instances, 332 bytes average size
- Final Heap: 6'308 bytes, 0.51% - 19 instances, 332 bytes average size
- Objects Finalized: 3'320 bytes, 4.17% - 10 instances, 332 bytes average size
Thanks again!- Hi,
From the summary data, the "Allocated bytes ", "Final Heap bytes " and "Objects finalized " have proper values, there is no doubt for those values, right?
For the data from "HistoGram ", take "Allocated" for example, seems you only pick up history data for one type, not for all types. 6,640 is apparently smaller than 2,086,758, so the instances' count 20 is just part of all allocated instances.
In the "HistoGram " form, we can get total statistics from the top line at the right panel, something like this:
Grand total: 260,365 bytes - 4,129 instances, 63 bytes average size
Thanks,
Eric
Please remember to mark helpful replies as answers and unmark them if they provide no help. - Hi Eric,
Thanks again for your answer (and patience ;-) ).
You are right that the data from 'Histogram' is only the data for one type, namely for the type 'TestForm'. This is exactly the type that I'm interested in. My question is how it is possible that in the example below there are 20 instances allocated, 19 instances in the final heap and 10 instances finalized?
- Allocated: 6'640 bytes, 0.32% - 20 instances, 332 bytes average size
- Relocated: 332 bytes, 1.59% - 1 instances, 332 bytes average size
- Final Heap: 6'308 bytes, 0.51% - 19 instances, 332 bytes average size
- Objects Finalized: 3'320 bytes, 4.17% - 10 instances, 332 bytes average size
Thanks - Hi,
Could you post your code here?
Thanks,
Eric
Please remember to mark helpful replies as answers and unmark them if they provide no help. - We are changing the issue type to “General Discussion” because you have not followed up with the necessary information. If you have more time to look at the issue and provide more information, please feel free to change the issue type back to “Question” by clicking "Change Type" at the top of the thread. If the issue is resolved, we will appreciate it if you can share the solution so that the answer can be found and used by other community members having similar questions.
Thanks,
Eric
Please remember to mark helpful replies as answers and unmark them if they provide no help.


