RFC: LD: Changing the size of the delta used when growing merge offset maps

[Nick Clifton]

Hi Michael,

>>    Running the linker under sysprof shows that the append_offsetmap()
>>    function in merge.c is responsible for a large amount of the memory
>>    allocated during a link, and a lot of those allocations are calls to
>>    bfd_realloc().  

> Have you tried to establish the best case possible for this scenario?
> Measure the maxsize of these and realloc that size right from the start,
> so that no reallocs are ever called in that run?

Hmm, no ...


> Thing is: every reallocation is interspersed with a fixed number of new
> offset/entry pairs for mergable sections, and each of these pairs is only
> created after parsing and hashing the sections contents.  So the final
> size of the offset map will be directly related to the number of hashed
> blobs in it, and hence roughly related to its size.  So another approach I
> considered but didn't follow up on, was to approximate the initial number
> of entries to (say) section-size divided by 16, guarded by some minimum
> and maximum, or to perhaps make the increment itself somewhat depending on
> that (i.e. large input sections will get a larger increment).

Actually that sounds like an interesting idea.  I may have a go myself.

> If we'd go with your patch 

I think that I am going to withdraw the patch.  It did not achieve enough
of a gain to make it really useful and your idea of preallocating enough
space at the start looks like it might be far more effective.

Cheers
   Nick