|
From: Josef W. <Jos...@gm...> - 2008-02-13 19:37:23
|
Hi Sébastien, On Wednesday 13 February 2008, Sébastien Sablé wrote: > 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. Sorry, I do not understand this. Why is the "filename" field not enough? Or is this a workaround for a usability problem in KCachegrind? > For some reason it only works with the > --compress-strings=no option. What it the problem here? The parser in KCachegrind? > 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. I have no idea about phython internals, so I can not comment on the usefulness of catching these additional functions. So you are "just" adding further artificial functions to the callgraph? > 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. Oh, then I misunderstood. When is "PyEval_EvalFrameEx" actually called? I thought this is a special run mode of Python, which needs modifications 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 if I want to try to abstract your needs for python from callgrind by adding client requests to define artificial function names for the call graph, this would mean an actual change of python, which currently is not needed? > 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...). Yes. However, there currently does not exist any further extension of VG tools to allow for "callgrind plug-ins". But it should be possible to make a kind of library version of callgrind, to base other VG tools on it. Or even better: Support it via just an configuration file (or command line options). Now that Julian is adding support for reading debug info for data, it should be possible to look up arbitrary variables. Josef > > regards > > -- > Sébastien Sablé > |