------- Additional Comments From dcoutts at gentoo dot org 2006-03-17 02:57 ------- Adding some instrumantation shows that the spike in memory use occurs within the function _bfd_compute_and_write_armap() in bfd's archive.c module.
It maps over each object file in the archive and allocates symbol tables for each one. This is where the linear memory use is comming from. Then when it's done collecting symbols it writes them out. Perhaps it'd be possible to change the algorithm so that we only need to keep the bfd resources for one archive member at a time. Afterall the code already copies out the information it will need for the final symbol index rather than leaving it shared with the archive member bfd structures. So as far as I can see it should be possible to only allocate bfd resources for one member of the archive at a time rather than allocating bfd resources for every archive member simultaniously. The size of the final symbol index is not that big (only a few Mb) so if the memory use were a small multiple of that size rather that a large multiple (x20) of the size of the whole archive then the memory savings would be quite significant. [And we wouldn't get complaints from users about the OOM killer kicking in while they build libHSbase.a ! :-) ] -- http://sourceware.org/bugzilla/show_bug.cgi?id=2467 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
