From mboxrd@z Thu Jan 1 00:00:00 1970 From: DJ Delorie To: ian@zembu.com Cc: dan@cgsoftware.com, jhaller@lucent.com, jtc@redback.com, cgf@redhat.com, gdb@sources.redhat.com, binutils@sources.redhat.com Subject: Re: stabs vs. dwarf-2 for C programs Date: Fri, 13 Apr 2001 22:37:00 -0000 Message-id: <200104140537.BAA20048@envy.delorie.com> References: <5mwv8pzgvt.fsf@jtc.redback.com> <20010412221742.A22383@redhat.com> <5mg0fdzg2t.fsf@jtc.redback.com> <3AD70931.CF488A07@lucent.com> X-SW-Source: 2001-04/msg00106.html > > I'm pretty sure this alone will cut linking time by a large factor, > > based on the number of seeks and the amount of time they are taking, > > in a few tests i just did. > > It's possible. Around 1997 or so I tried using mmap as you suggest. > It actually made the linker slower on the systems I tested it on, > including Solaris and on the Linux kernel, so I dropped the effort. > But, as you say, times change, and maybe now it would indeed be > faster. It's an easy optimization in BFD; why don't you try it? One of the optimizations in DJGPP's runtime library is specifically because the linker does a lot of seeks (other programs, like gcc, tend to stream data instead). We changed the buffer size dynamically to adapt to random vs linear accesses. Of course, this assumes your default buffer size is bigger than a sector anyway. Linux seems to have a 4k buffer; try setting the buffer size to 512 for all bfds in the linker and see if it improves performance.