This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FYI GDB on-disk .debug cache (mmapcache) [Re: Tasks]


>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Tom> * Maybe we could play some trick to speed up strcmp_iw_ordered.

Jan> But it affects only the CPU usage, not the disk access times.

Yeah :(

Tom> This is an interesting idea, though I find it a bit hard to reconcile
Tom> with the I/O wait theory.  Perhaps we would be reading strictly less
Tom> data.

Jan> Yes, I see now that the idea was naive.

I wouldn't say that!

Jan> I would try dwarf2_build_psymtabs_easy() myself now, so far just
Jan> with the public symbols (regressing GDB).  If it would be fast
Jan> GCC can provide even indexes for the static symbols.

I re-did my profiling on the pubnames case.  The do-nothing
dwarf2_build_psymtabs_easy does cut down the CPU time a lot.
It does still read the contents of debug_pubnames, so the mystery time
does not disappear:

/usr/bin/time using _hard: 45.73user 2.74system 1:18.35elapsed 61%CPU
/usr/bin/time using _easy:  8.84user 3.01system 0:56.95elapsed 20%CPU

Of course it is hard to say what the improvement would really look
like when the _easy stuff is actually in place.  20 seconds maximum
improvement here ... that is nice but hardly in "awesome" territory.

It seems weird that the elapsed time does not vary as much as the user
time.  I wonder what that means.


So -- at least to me it is not obvious what to do.  Hiding the time
(not reading anything until needed) is nice for attach, but, I think,
won't hugely improve the user experience (unless we can somehow also
avoid reading a lot of the data in all cases).

Maybe we could do something like your patch, but rather than mmap the
data structures, store compressed data structures, on the theory that
we would trade size on disk for some cpu.

Maybe we could hide the work somewhere else -- try to bring up the
"user interface" as quickly as possible but have a dwarf-reading
thread in the background.  (This occurred to me while writing this
note.  So, I assume it has some killer flaw :)

I think my next step is to learn even more and see if I can find
exactly where the time is being spent.

Another thing I am curious about is seeing how elfutils fares on this
case.

In any case I think I am getting to the point where I could produce
some kind of estimate -- at least estimating some concrete tasks, plus
some of the more time-consuming investigations.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]