Hi Milian, On Thursday 15 July 2010, Milian Wolff wrote: > Would the callgrind data allow grouping by thread in KCacheGrind's > evaluation? > Isn't something like > > myMethod()'X > > indicating the thread number with the X?
Short explanation of the usage of "'": A symbol can contain multiple parts specifying some dynamic context, such as parent stack frames (thus providing the call chain to the function where the costs happend), or the recursion depth (if X is an integer). These parts are separated by apostrophes (*). While the thread number could be seen as an dynamic context, neither callgrind is able to use the thread number in this way (ie. to create symbol names with suffix 'X with X being the thread number), nor KCachegrind currently would be able to separate profile data by symbol suffixes. But you should be able to reach your goal by using "--separate-threads=yes". This will ask callgrind to produce multiple profile dumps, one for each thread. And you can just load the data for thread 1, for example. Does this answer your question? Best, Josef (*) encoding the parent frames into the symbol names is requested via "--separate-callers=n", and this is a very good way to avoid false cycles showing up in the profile data. However, KCachegrind currently does not parse the apostrophes, but just shows the full symbols with the long suffixes encoding the call chains. This gives quite ugly, long names... I am currently implementing support for extracting the meaning of the apostrophes. In the end, KCachegrind will present the data the same as if there was no "--separate-callers" used; just a lot of false cycles will disappear. Also, the flat profile will group different dynamic contexts in hierarchies, allowing you to e.g. show costs of function X only when called from Y with Y called from Z (no idea if anybody wants to see such crazy stuff, but as callgrind measured it, that data should be accessable). Now if I would start to mix different semantics into "foo'X", it would get more difficult for KCachegrind to actually making sense from it. > I ask since when profiling a big application, it is sometimes neccessary to > find > hotspots that lead to blocks in the UI. They might be much less resource > intensive than what's done in the background (i.e. you won't find them just > by > looking at total costs). In Qt at least (and afaik other toolkits as well), > all UI related stuff is done in Thread 1. If it would be possible to limit > ones > view to that thread, it could become much easier to find user noticable lags. > > What do you think? > > Bye ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
