|
From: Josef W. <Jos...@gm...> - 2006-08-07 21:08:14
|
On Monday 07 August 2006 22:21, you wrote:
> I was thinking of two cases here: source files that are compiled but not
> linked and source files that aren't even compiled. Being able to flag
> these files (large projects can often end up with this sort of "fluff"
> lying around) would assist further in cleanup / test development.
I am not sure, that "not even compiled files" should influence the coverage.
How do you want to detect them? Of course, debug info is not available for
such files, and you would need to parse them yourself.
> > With "lineWithCode", the problem to show huge context should be gone.
>
> A "show entire file" option might be a nice alternative?
Hmm... yeah, I could put this option into the context menu for
source annotation. The same for assembler annotation (show disassembler
of full object) is probably not such a good idea...
>
> >
> >> The "ignores some files" thing is because I can only have 499 items in a
> >> list box.
> >
> > ??
> > Sorry, where does this limitation come from? Are you talking about
> > Covergrind or KCachegrind?
>
> KCachegrind: the list box in the bottom left shows something along the
> lines of "ignoring X files < Y". By increasing the list box size in the
> options dialog up to 499 on my small test run, this problem goes away.
> The 500 limit is way to small for some of the stuff I intend to run this on.
Ah, I see. The 500 was a pure arbitrary limit, to keep the GUI snappy;
some limit is needed because Qt3 creates for every list item an object,
so huge lists are both time/space consuming (and running OpenOffice, you
easily get 50000 functions). This will be moot with Qt4, as list items
use the applications own model there, so huge lists do not add any
overhead. However, with profiling, you usually are only interested in the
top entries.
> >> This is going to be a major headache at work where the file
> >> count is well above 1000 (and probably at least 2000).
> >
> > Hmm, shouldn't be a problem.
>
> It should handle the files, I just wont be able to select them all
> because the list box wont display more than 499.
Yup.
> If it is doing a binary search, (without looking at the code) it might
> be possible to adapt it / generate another function to walk part of the
> list / tree, calling a passed in function pointer or some such. I will
> have a look at this as simple access to the results of the parsing
> output but in a linear format based on source lines would be really
> useful. I will see what I can do and post some patches
Sure, some useful extension of the tool API is always welcome.
> The new functionality could possibly even return something like:
>
> struct lines {
> int size;
> char *bits;
> }
>
> where size is the amount of memory malloced onto bits and bits are set
> based upon line number:
>
> bits[line_num / (sizeof(char) * 8)] |=
> (1 << (line_num & (((sizeof(char) * 8) - 1)));
Hmm, this looks already quite complicated. Why not an iterator function?
Josef
|