E-mail request for hprof RFE:
Apologies if this is not the correct list for this post - please
redirect me if that's the case.
I'd like to suggest adding an option to the hprof profiler to disable
heap profiling entirely, in addition to the current options of "site",
"dump" and "all".
Background:
I have recently been making extensive use of hprof for CPU profiling
some Hadoop code. In the course of this, I've noticed that the having
the heap profiler enabled, even with just "sites" mode, results in
non-negligible amount of overhead in object allocation. This results
in the CPU samples reported being considerably skewed in any code that
makes large numbers of allocations. I've seen cases of the profiler
reporting > 80% of execution time being spent in object allocation,
but for the normal code path it is actually of negligible cost.
I patched a version of hprof to add a "none" option, which disables
both heap dump and allocation site profiling. Using this results in
CPU profiles which seem to more accurately reflect the normal code
execution.
(this was simply adding the following code to hprof_init.c:623):
} else if (strcmp(suboption, "none") == 0) {
gdata->heap_dump = JNI_FALSE;
gdata->alloc_sites = JNI_FALSE;
It seems like this might be a useful feature for other users.
R
Apologies if this is not the correct list for this post - please
redirect me if that's the case.
I'd like to suggest adding an option to the hprof profiler to disable
heap profiling entirely, in addition to the current options of "site",
"dump" and "all".
Background:
I have recently been making extensive use of hprof for CPU profiling
some Hadoop code. In the course of this, I've noticed that the having
the heap profiler enabled, even with just "sites" mode, results in
non-negligible amount of overhead in object allocation. This results
in the CPU samples reported being considerably skewed in any code that
makes large numbers of allocations. I've seen cases of the profiler
reporting > 80% of execution time being spent in object allocation,
but for the normal code path it is actually of negligible cost.
I patched a version of hprof to add a "none" option, which disables
both heap dump and allocation site profiling. Using this results in
CPU profiles which seem to more accurately reflect the normal code
execution.
(this was simply adding the following code to hprof_init.c:623):
} else if (strcmp(suboption, "none") == 0) {
gdata->heap_dump = JNI_FALSE;
gdata->alloc_sites = JNI_FALSE;
It seems like this might be a useful feature for other users.
R