* Re: parallelized 'ld'?
[not found] ` <87d6f63jes.fsf@muq.org>
@ 2003-08-16 14:46 ` Andrew Cagney
2003-08-18 0:40 ` Alexander Smundak
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2003-08-16 14:46 UTC (permalink / raw)
To: Cynbe ru Taren; +Cc: Paul Hilfinger, gdb, Alexander Smundak
[switching mailing lists from binutils@ to gdb@]
> * "gdb used to take inordinate amount of time to load on our platform. The
> fix was trivial, which likely means that few people ever use GDB on
> such large executables."
I believe one identified problem is how the symbol table uses hash
tables. The symbol tables are being given a careful upgrade. Was this
what you noticed?
As for using GDB on large programs, mozilla is (or was) the reference -
its startup has gone from impossible to tolerable. I believe users now
also have their sights on eclipse (compiled with gcj). So increasing
demand is definitly there.
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: parallelized 'ld'?
2003-08-16 14:46 ` parallelized 'ld'? Andrew Cagney
@ 2003-08-18 0:40 ` Alexander Smundak
2003-08-18 15:06 ` Andrew Cagney
0 siblings, 1 reply; 4+ messages in thread
From: Alexander Smundak @ 2003-08-18 0:40 UTC (permalink / raw)
To: Andrew Cagney, Cynbe ru Taren; +Cc: gdb
> [switching mailing lists from binutils@ to gdb@]
>
> > * "gdb used to take inordinate amount of time to load on our platform.
The
> > fix was trivial, which likely means that few people ever use GDB on
> > such large executables."
>
> I believe one identified problem is how the symbol table uses hash
> tables. The symbol tables are being given a careful upgrade. Was this
> what you noticed?
No, it is handling BINCL records in STABS. I have replaced the linear search
in dbxread.c, function find_corresponding_bincl_psymtab() with hash table,
and this shaved 3 minutes off the GDB initialization time in our case
(on 333MHz Sparc Ultra).
Please note that our compiler is gcc 2.95, and that this is for STABS
debugging
format. I can send the diffs to the interested parties; they are for 5.0
GDB, though.
Alexander Smundak
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: parallelized 'ld'?
2003-08-18 0:40 ` Alexander Smundak
@ 2003-08-18 15:06 ` Andrew Cagney
2003-08-18 19:02 ` Alexander Smundak
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2003-08-18 15:06 UTC (permalink / raw)
To: Alexander Smundak; +Cc: Cynbe ru Taren, gdb
> [switching mailing lists from binutils@ to gdb@]
>>
>
>> > * "gdb used to take inordinate amount of time to load on our platform.
>
> The
>
>> > fix was trivial, which likely means that few people ever use GDB on
>> > such large executables."
>
>>
>> I believe one identified problem is how the symbol table uses hash
>> tables. The symbol tables are being given a careful upgrade. Was this
>> what you noticed?
>
> No, it is handling BINCL records in STABS. I have replaced the linear search
> in dbxread.c, function find_corresponding_bincl_psymtab() with hash table,
> and this shaved 3 minutes off the GDB initialization time in our case
> (on 333MHz Sparc Ultra).
> Please note that our compiler is gcc 2.95, and that this is for STABS
> debugging
> format. I can send the diffs to the interested parties; they are for 5.0
> GDB, though.
Ah. Unless you/cisco have an assignment, a bug report pointing at the
offending code would be better.
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: parallelized 'ld'?
2003-08-18 15:06 ` Andrew Cagney
@ 2003-08-18 19:02 ` Alexander Smundak
0 siblings, 0 replies; 4+ messages in thread
From: Alexander Smundak @ 2003-08-18 19:02 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Cynbe ru Taren, gdb
Andrew,
> >> I believe one identified problem is how the symbol table uses hash
> >> tables. The symbol tables are being given a careful upgrade. Was this
> >> what you noticed?
> >
> > No, it is handling BINCL records in STABS. I have replaced the linear
search
> > in dbxread.c, function find_corresponding_bincl_psymtab() with hash
table,
> > and this shaved 3 minutes off the GDB initialization time in our case
> > (on 333MHz Sparc Ultra).
> > Please note that our compiler is gcc 2.95, and that this is for STABS
> > debugging
> > format. I can send the diffs to the interested parties; they are for 5.0
> > GDB, though.
>
> Ah. Unless you/cisco have an assignment, a bug report pointing at the
> offending code would be better.
It turns out there is already an open PR#975:
Reporter's email:klee@apple.com
Number:975
Category:symtab
Synopsis:[RFA] Use hash to speed up BINCL/INCL processing.
Severity:serious
Priority:medium
State:open
Arrival-Date:Thu Jan 30 04:48:00 UTC 2003
Last-Modified:Sun Feb 16 04:18:00 UTC 2003
Alexander Smundak
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-08-18 19:02 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <200307150234.h6F2YsNW028337@tully.CS.Berkeley.EDU>
[not found] ` <87d6f63jes.fsf@muq.org>
2003-08-16 14:46 ` parallelized 'ld'? Andrew Cagney
2003-08-18 0:40 ` Alexander Smundak
2003-08-18 15:06 ` Andrew Cagney
2003-08-18 19:02 ` Alexander Smundak
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).