Identifying cause of clr.dll CPU time

When profiling, is there a way to determine the source of samples attributed to clr.dll?

I am writing a bin packing algorithm, and while it is relatively quick, it is critical for it to be faster. Right now, 80% of the samples are in clr.dll, and I am unsure where to focus my efforts.

Would garbage collection show up as clr.dll, if at all? Array.Copy? Memory allocation? Casting?

Though I do avoid a lot of memory allocation and collection, the speed at which the algorithm churns through potential configurations means it is allocating and collecting pretty much constantly. The garbage collection markers form a solid yellow line. Further reducing garbage collection would require other sacrifices as well as a significant time investment, and I would like some kind of confirmation that GC is the culprit before I commit.

submitted by /u/MeDanP
[link] [comments]

Leave a Reply