Very cool, py-spy[1] has been an invaluable tool in my development process since jvns blogged[2] about it. The power of being able to visualize where your code is spending its time is so obvious and I'm glad people are building tools to make that easier.<p>As a quick compare and contrast between py-spy and pyinstrument it looks like py-spy has the advantage of being able to attach to an already running process which is super useful when your program is stuck and you don't know why. I haven't used pyinstrument yet but I do like the fact that it can do its flame graph in the console, sometimes I find saving down an svg file and opening up the browser a bit arduous. Excited to give it a try.<p>[1] <a href="https://github.com/benfred/py-spy" rel="nofollow">https://github.com/benfred/py-spy</a><p>[2] <a href="https://jvns.ca/blog/2018/09/08/an-awesome-new-python-profiler--py-spy-/" rel="nofollow">https://jvns.ca/blog/2018/09/08/an-awesome-new-python-profil...</a>
>
The standard Python profilers profile and cProfile show you a big list of functions, ordered by the time spent in each function. This is great, but it can be difficult to interpret why those functions are getting called. It's more helpful to know why those functions are called, and which parts of user code were involved.<p>Note that you can use something like gprof2dot to convert pstats dump from cProfile to a visual callgraph: <a href="https://github.com/jrfonseca/gprof2dot#python-cprofile-formerly-known-as-lsprof" rel="nofollow">https://github.com/jrfonseca/gprof2dot#python-cprofile-forme...</a><p>Not saying that solution’s better than pyinstrument — I haven’t use this one before so I’ll have to evaluate. Also, the lower overhead is undeniable.<p>---<p>Edit: Another thing I noticed in "How is it different to profile or cProfile?":<p>> 'Wall-clock' time (not CPU time)<p>> Pyinstrument records duration using 'wall-clock' time. ...<p>Seems misleading as cProfile uses time.perf_counter unless you supply your own timer, and time.perf_counter does measure wall clock time. See<p><a href="https://github.com/python/cpython/blob/ec42789e6e14f6b6ac13569aeadc13798d7173a8/Modules/_lsprof.c#L106-L115" rel="nofollow">https://github.com/python/cpython/blob/ec42789e6e14f6b6ac135...</a><p><a href="https://docs.python.org/3/library/time.html#time.perf_counter" rel="nofollow">https://docs.python.org/3/library/time.html#time.perf_counte...</a>
The title for this post has a typo - it should be "profileR", not "profile" (er, without the capitalization on the R :) )<p>I could guess from context, but thought it might be good to point out.<p>Source: From the repo:
"Pyinstrument is a Python profiler"<p>(Feel free to delete this comment after fixing the typo, or not :) )
I'm a big fan of pyinstrument. Many of the newer profilers, (e.g. py-spy) attach to a process externally via SYS_PTRACE and though that seems great in many ways, it is very much a no-go when you're running code on an HPC cluster and you don't have root access.
I like how easy this is to wire up to a Django API, took me a few seconds to this hooked up on my local machine.<p>This gives nicer summarization/presentation than Django Debug Toolbar's profiler, so seems like a good one to have in the toolbox.
How does it compare with yappi[1]?<p>[1] <a href="https://github.com/sumerc/yappi" rel="nofollow">https://github.com/sumerc/yappi</a>
> Shows you why your code is slow!<p>Because you wrote it in Python.<p>Seriously, Python is probably the slowest mainstream language of all. If you’re building something where performance matters, you should be using a different language.