|
From: Nicholas N. <nj...@ca...> - 2004-07-05 20:27:31
|
On Mon, 5 Jul 2004, Josef Weidendorfer wrote: >> I've made these changes. The improvement are pretty big. I've include >> the change log below, check out the general improvements. They arose >> because I split one messy data structure, which was (I now realise) >> serving two distinct purposes, into two much cleaner data structures. > > I always thought that this mix up was because of getting better cache > behaviour (more spatial locality) of cachegrind ... which obviously is not > true? No! I just hadn't thought about it in the right way. :) > One problem is that Calltree has an option to dump out events by their > instruction address (actually object file offset), and KCachegrind > uses this for annotated dissassembler. I don't want to loose this feature, > especially as I think it is important for the user to be able to look at this > detail level if needed. > > But your separation is a very good thing. I'm sure this will give similar > simplifications. Instead of a CC per distinct source line, can't we use a CC > per (obj_file/instruction offset) which is mapped to a distinct source line? > I know that this makes things a little bit more complex, but still the CCs > don't have to be discarded on unmapping code segments. Yes, an object file location, rather than a source file location, could be suitable for Calltree for this purpose. But I want to stick with the source file location for Cachegrind. > Is a CC per distinct source line enough? E.g. all initialisation functions of > shared libraries, where you don't have source code, will be mapped into one, > as the functions are called the same (_init). Yes, but if you don't have source code then you can't do annotation and so the information collected for that library won't be used anyway. So it's good that it's been compacted so much and takes up very little space in the cachegrind.out file. >> - Removed "fi" and "fe" handling from cg_annotate, no longer needed due >> to neatening of the CC-table. > > What actually was the purpose here? Why wasn't "fn=" in all cases enough? I can't remember exactly... it was something to do with cross-module inlining, which meant that the instructions within a basic block could have different filenames, and so it had to switch back and forth between files. Or something like that. N |