4 ms·
Maybe I missed something, but using cProfile to read the produced stats is a bit of a pain in the neck. I was debugging a django application, where every reques
by herge 11y ago
Maybe I missed something, but using cProfile to read the produced stats is a bit of a pain in the neck. I was debugging a django application, where every request involves a large call stack either through the django web server or (in my unfortunate case) through the templating library, so a lot of cruft was in the profile. I had to dig through the underlying dicts that made up the stats output.
- mrfusion 11y agoIsn't django slowness usually database related? In that case I find the the django debug toolbar gives a ton of useful information.
- LukaAl 11y agoYes, this is usually a problem. A better way to use cProfile is to run it and save the results in a pStat file and then, in iPython you can load the file using the Stats class [0]. With the class you could easily change the ordering without having to re-run the command (very useful when the command take several minutes). Also allows you to apply filters (cut the number of lines or apply regular expression) to the output. Usually I filter for the one/two file where most of my custom code is and I check for the hotspot; this remove all Django related calls. Then I select a good candidate for optimization and I dig that functions looking at the code (restrictions are useful in many way). It is a long process, but much less painful than you could expect. But probably it should have a well designed interface to make it easier to use. [0] https://docs.python.org/2/library/profile.html#the-stats-class https://docs.python.org/2/library/profile.html#the-stats-cla...