This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: DLL linking performance


Hello Pascal,

if you plan to switch to v1, this is a really bad idea in general.
Anyway, just to make point out for others, the cause for this DLL
load-delay isn't caused by the ld-code in any case.  It is an issue of
the pseudo-relocation code in use of runtime.  Older code has here
shown some issue about doing section-write-permission changes for each
relocation-entry instead of doing it once per relocated section.

So this issue is nothing to be solved in binutils at all.  There is a
fix for this issue already present in mingw-w64's startup-code, but
this patch can't be used in mingw.org's runtime, as there some
required startup-features for hasing sections are not present .

 The link-delay you are noticing for v1 is caused by section-attribute
changes for allowing write on read-only sections.  There is actual no
real time-difference between v1 and v2, beside that sections getting
marked temporary writeable.  The amount of relocation between both
versions is identical.

Regards,
Kai


2012/3/29 Pascal Obry <pascal@obry.net>:
>
> Hi There!
>
> Following the previous discussion with Kai about the DLL load time
> performance I have switched the linker to use the runtime pseudo reloc
> v1 circuitry.
>
> This indeed has made a big difference in loading the DLL, it is now
> almost instantaneous where it was more than 2 minutes before.
>
> But now the DLL *link* time has regressed at lot. My initial test shows
> that creating the DLL is 5 times slower.
>
> I've been analyzing this issue. Here are my findings:
>
> - There is two sorts routines un ldlang.c
>
> ?wild_sort and wild_sort_fast
>
> ?As the later imply it is fast and the former is slow.
>
> - Those sort routines get called from
>
> ?output_section_callback and output_section_callback_fast respectively.
>
> - Those routines are called from wild:
>
> ? static void
> ? wild (lang_wild_statement_type *s,
> ? ? ? ? const char *target ATTRIBUTE_UNUSED,
> ? ? ? ? lang_output_section_statement_type *output)
> ? {
> ? ? struct wildcard_list *sec;
>
> ? ? if (s->handler_data[0]
> ? ? ? ? && s->handler_data[0]->spec.sorted == by_name
> ? ? ? ? && !s->filenames_sorted)
> ? ? ? {
> ? ? ? ? lang_section_bst_type *tree;
>
> ? ? ? ? walk_wild (s, output_section_callback_fast, output);
>
> ? ? ? ? tree = s->tree;
> ? ? ? ? if (tree)
> ? ? ? ? ? {
> ? ? ? ? ? ? output_section_callback_tree_to_list (s, tree, output);
> ? ? ? ? ? ? s->tree = NULL;
> ? ? ? ? ? }
> ? ? ? }
> ? ? else
> ? ? ? walk_wild (s, output_section_callback, output);
>
>
> The fast routine is called when the data are sorted. Do you think this
> can be improved? ?Where is this sort should be done?
>
> My initial investigation seems to indicate that this sorting status is
> done on the linker script (SORT_BY_NAME), but I'm lost in the code...
>
> Any guidance will be much appreciated.
>
> Thanks.
>
> Pascal.
>
> --
>
> --|------------------------------------------------------
> --| Pascal Obry ? ? ? ? ? ? ? ? ? ? ? ? ? Team-Ada Member
> --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
> --|------------------------------------------------------
> --| ? ?http://www.obry.net ?- ?http://v2p.fr.eu.org
> --| "The best way to travel is by means of imagination"
> --|
> --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
>



-- 
|? (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]