Today I tested the performance of Jandy-python profiler with my sample Django project.
Profiling time was measured which starts and ends with running profiler.
The result time(second) is as below.
And it looks like other profilers don't use "settrace" function.(at least as a default option.)
Python "signal" is used instead and it has lower overhead.
But "signal" doesn't support inter-thread communication. So we need other approach if we use this.
yappi <- This profiler supports multithread profiling.
Below is the Github page of other profilers that I used this time.
Today I tested the performance of Jandy-python profiler with my sample Django project. Profiling time was measured which starts and ends with running profiler. The result time(second) is as below.
Jandy-python profiler spent a lot more time than others. And I could figure out that compiled code execution time was almost same with the profiler exit time.
Until now I think "settrace" function inside profiling code makes some problems. I found some info about this function. http://stackoverflow.com/questions/1692866/what-cool-hacks-can-be-done-using-sys-settrace/1693108#1693108
And it looks like other profilers don't use "settrace" function.(at least as a default option.) Python "signal" is used instead and it has lower overhead.
But "signal" doesn't support inter-thread communication. So we need other approach if we use this. yappi <- This profiler supports multithread profiling. Below is the Github page of other profilers that I used this time.