I am using PerfView to tune an application, and the second most expensive item is currently tagged as:
OTHER < < clr!JIT_New > >
at over 10% of CPU. This continues even for subsequent runs of the test case.
Can anyone identify what activities or code practices might be causing the dynamic generation of new code requiring JIT-ting?
JIT_New() is a helper function inside the CLR that runs whenever you create a new object in your code with the new operator. It just allocates memory from the garbage collected heap and calls the class constructor. Or in other words, it implements the Opcodes.Newobj IL instruction. Its name is a bit confusing, it doesn't have anything to do with jitting your code. Just a helper function that the jitter knows about, it compiles a call to this helper function directly into the generated machine code. JIT_Newarr1() would be another one you'd encounter, it allocates an array.
I don't know PerfView, do note that the execution time for JIT_New() may include the time needed to perform garbage collections. Which occur when the gen#0 heap is full when JIT_New() runs. Which would explain the large percentage, JIT_New() is otherwise extremely fast. Nothing much you can do about it, this is fixed overhead in any managed program.
structs instead. Do you happen to know if a boxing overhead is incurred to implement IEquatable<T> on a struct? I saw something recently that suggested so. –
Pulsifer © 2022 - 2024 — McMap. All rights reserved.
JIT_New()includes the time taken for garbage collection is correct (and I believe it is), then it's not strictly true that there's "nothing much you can do about it": in many cases, it's worthwhile running the program under a good memory profiler and figure out how to create fewer objects (i.e., less garbage). A high "% time in GC" performance counter can be indicative of a poorly-written program. – Dilatant