This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: pstats - allow stats sorting by cumulative time per call and total time per call
Type: enhancement Stage: patch review
Components: Library (Lib) Versions: Python 3.4
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: alexnvdias, danielnoord, georg.brandl, jstasiak, python-dev, r.david.murray, ramnes
Priority: normal Keywords: patch

Created on 2013-08-20 23:48 by alexnvdias, last changed 2022-04-11 14:57 by admin.

File name Uploaded Description Edit alexnvdias, 2013-08-20 23:48 pstats source code with patch added
pstats-diff-issue18795.txt alexnvdias, 2013-08-21 10:06 Diff of patch against current version of pstats (Aug 21 2013) review
Pull Requests
URL Status Linked Edit
PR 31919 open python-dev, 2022-03-15 23:27
Messages (9)
msg195731 - (view) Author: Alexandre Dias (alexnvdias) * Date: 2013-08-20 23:48
Me and a couple of colleagues have stumbled upon the need to sometimes sort our profiling stats by time (cumulative and total) per call. I believe this could be useful to other people, and have therefore opened this patch.

Thanks for taking the time to look into it.

msg195762 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-08-21 09:58
I believe the module already supports sorting by time and cumulative time (determining the top consumers of cpu is a major part of the point of the profile module, after all).  

What exactly is the change that you are proposing?  If you post a diff instead of a modified copy of the module it would be easier to see what you are proposing.
msg195763 - (view) Author: Alexandre Dias (alexnvdias) * Date: 2013-08-21 10:06
It does support sorting by total time and cumulative time spent on a function, but not by the time per each call of that function.

I've uploaded a diff of the patch.

msg195767 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-08-21 10:25
It would be clearer, I think, to call it average time.  I must admit to not being sure why that is useful.  I'm also worried there might be backward compatibility issues with changing the ordering of the data structure.  If new fields are going to be added they should probably be added at the end.
msg195819 - (view) Author: Alexandre Dias (alexnvdias) * Date: 2013-08-21 20:22
Average time would indeed be a better description. 

As for its usefulness: let's say that for example you would want to find the function in which your code spends the most time on average, in order to later optimise said function. If one of the calls to another function has its execution time spike momentarily, it will be at the top of the total time column on the result. However, that does not necessarily mean that it was the function in which on average the most time was spent on, and thus the one that the optimisation effort should be focused on.
Also, when seeing the profiling results, I would expect to be able to sort by any of the columns shown, and that is currently not possible for the average cumulative and total time per call.

Do you mind clarifying your worries with backwards compatibility? Unless I'm mistaken, "fcn_list "is the only outside effect of the method I'm changing. It is built from the last element of each tuple in stats_list, whose ordering is what I'm proposing to be able to change (thus changing the ordering of the function list, but that is already done by other sort options).
msg195821 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-08-21 20:57
There may not be a problem.  I'm not familiar enough with the pstats code to review the patch for real without some study.
msg196753 - (view) Author: Jakub Stasiak (jstasiak) * Date: 2013-09-01 23:39
I'd change cumulativepercall and totalpercall to cumpercall and percall (and/or intpercall) but that's a detail, this patch works for me.

Data structure affected by this patch is produced and consumed internally by the sort method so it looks like nothing changes from the point of view of client code.
msg209544 - (view) Author: Alexandre Dias (alexnvdias) * Date: 2014-01-28 13:08
Could I get an update on this please?
msg415305 - (view) Author: Daniël van Noord (danielnoord) * Date: 2022-03-15 23:29
I resubmitted the original patch and updated it with documentation and news item changes.

This would still be a valuable addition imo, as it can help single out expensive calls in your module/script.
Date User Action Args
2022-04-11 14:57:49adminsetgithub: 62995
2022-03-15 23:29:12danielnoordsetnosy: + danielnoord
messages: + msg415305
2022-03-15 23:27:21python-devsetkeywords: + patch
nosy: + python-dev
pull_requests: + pull_request30009
2014-02-11 18:05:06ramnessetnosy: + ramnes
2014-01-28 13:08:02alexnvdiassetmessages: + msg209544
2013-09-01 23:39:22jstasiaksetnosy: + jstasiak
messages: + msg196753
2013-08-23 19:22:34ezio.melottisetnosy: + georg.brandl

stage: patch review
2013-08-21 20:57:41r.david.murraysetmessages: + msg195821
2013-08-21 20:22:43alexnvdiassetmessages: + msg195819
2013-08-21 10:25:17r.david.murraysetmessages: + msg195767
2013-08-21 10:06:15alexnvdiassetfiles: + pstats-diff-issue18795.txt

messages: + msg195763
versions: + Python 3.4, - Python 2.7
2013-08-21 09:58:05r.david.murraysetnosy: + r.david.murray
messages: + msg195762
2013-08-20 23:48:11alexnvdiascreate