|
From: Sébastien S. <sa...@us...> - 2008-02-13 17:35:34
|
Hi Josef, I improved my patch so that python calls can now be sorted by "ELF object" in Kcachegrind, each "ELF object" representing a different python script. For some reason it only works with the --compress-strings=no option. I also found that I could get much more information about the Python context when calling Python C/API. This is useful for example to profile Python extension written in C or Pyrex. (this is done by instrumenting additional functions like PyObject_Call, PyObject_GetAttr...). It has the extra advantage of breaking many cycles, so that the trace is much easier to read in Kcachegrind. There is probably a lot more that can be done, and I will complete this patch in coming days. I intend to post an announce about it on python-users and pyrex mailing list once a more complete patch is available in order to get feedback from Python users. Josef Weidendorfer a écrit : > But to be true, the current solution looks quite "hacky" to me. To use it, > one has to modify things in the python interpreter, and there is > this special case for python in callgrind. Up to now, callgrind is independent > from the language used, as long as there exists debug information for the binary. This patch does not need any modification on the Python side. You can run callgrind with this patch on the standard Python interpreter or any C application linked with the Python libraries and it should work. However you are right that it is "hacky" in that it brings some code specific to Python in callgrind and some dependencies on the Python headers. > So, one way would be to add the patch as user contribution into a contrib/ directory. > And if there is enough pressure for a distribution, it could provide the patched callgrind. > > Or I try to refactor most parts of callgrind to make it available as modules for other > tools. And callgrind itself would shrink dramatically in code size. Not really realistic. > > Another way would be to try to achieve the same/similar result with a more general > solution not specific for python, but for any type of interpreter. > E.g. using client requests, which allow to specify function calls/returns > happening in a high-level call-graph. I suppose that your PyEval_EvalFrameEx > function would be the ideal place to notify callgrind about these events. > Hmm... this would add another dimension to the code position such as > (high-level function, low-level function), and thus to some "explosion" of positions. > In fact, it is quite similar to another dimension I wanted to add since quite some time: > accessed data. I just wonder if there is an easy extension of the format and > visualization, or if it is not really worth it... A patch in contrib/ would be fine for the moment. But I am sure that a generic way to push higher level functions would interest a lot of people (so that there could be some callgrind plug-ins to profile python2.5, python2.3, php, perl, whatever...). regards -- Sébastien Sablé |