Re: patch / RFD: speed up linker map file generation

[Nick Clifton <nickc at redhat dot com>]

Hi Joern,

  Sorry for the long delay in replaying to this email. :-(

Thanks very much fir developing this patch.  I think that it is 
definitely a good idea.

> I'm also not quite sure where we stand with memory consumption vs. speed.
> The linear time algorithm needs two pointers per hash table entry to
> form the linear lists.  The hash table entries appear to be the size of five
> pointers, and the overhead with objalloc_alloc / obstacks should be
> negligible.  Thus, it appears the memory used by defined symbols will grow
> by 40% when creating a map file with the linear time algorithm.
> So, should the linear time algorithm be the only one, on the grounds that
> quadratic time tends to hurt you much sooner than the 40% memory increase?
> Or should there be an option to use the old algorithm for people who simply
> can't create enough swap for the linker to create a map file with the new
> algorithm, but are prepared to wait a few hours for the result?

There should definitely be an option.  There are users who run these 
tools on small machines who will want the old behaviour.  I would 
suggest making it a generalised switch  (eg --reduce-memory-overheads) 
that can be used to trigger other (as yet unimplemented) tweaks to the 
linker's behaviour.

A few, minor, comments on the patch:

> +  /* For output sections: pointer to the section where this data will go */

Comment formatting: Please could we have a full stop and a couple of 
spaces at the end of the comments ?  (I know that the comments that you 
are replacing did not have this, but that should be no reason not to 
follow the guidelines).

> +static void init_map_userdata
> +  PARAMS ((bfd *, asection *, PTR));

Were are using ISO C now so we do not need to use the PARAMS() macro.

Cheers
  Nick