Re: [PATCH] Speed up ld by about 5 times on Windows.

[Brian Dessent <brian at dessent dot net>]

Sonal Santan wrote:

> I have a PATCH for speeding up GNU ld for PE-COFF by about 5 times. I
> had posted this patch last week to binutils mailing list, but saw no
> response. Should I be posting this to MinGW mailing list instead?

No, you posted to the right place.  I can't speak for Mingw but I don't
think they are interested in maintaining local patches, and besides,
mingw is not the only PE/COFF target.

Sometimes it just takes a while for patches to be reviewed.  However,
you can speed this process along by reformatting your changes according
to the GCS: <http://www.gnu.org/prep/standards/standards.html>.  For
example, multi-line comments like this:

+ /*
+  * Build a Binary Search Tree to sort sections, unlike insertion sort
+  * used in wild_sort(). BST is considerably faster if the number of
+  * of sections are large.
+  */

should be written as:

/* Build a Binary Search Tree to sort sections, unlike insertion sort
   used in wild_sort(). BST is considerably faster if the number of
   of sections are large.  */

Note the two spaces at the end.  Braces should go on a line by
themselves, so things like this:

+   if (tree->left) {
+     output_section_callback_tree_to_list(ptr, tree->left, output);
+   }

should be written as

  if (tree->left)
    {
      output_section_callback_tree_to_list (ptr, tree->left, output);
    }

Although for single line blocks you can skip the braces entirely.  There
should be no space after * in a declaration, but always a space before (
in a function call, and after a cast, so:

char *x = (cast *) foo (bar);

not

char * x = (cast *)foo(bar);

You included your patch inline and some lines were wrapped, which means
it will not apply without a great deal of cleanup work.  Therefore you
should always send your patch as an attachment, not inline.

You also should supply a ChangeLog that follows the GCS.  But do not
include changes to the ChangeLog in the patch (as the ChangeLog file is
very likely to change often), instead just include the ChangeLog entry
as plaintext in your message.

These things may seem like minor nits, but if a strict coding style was
not enforced the code would quickly turn into a jumbled mess, so this is
required before your patch can be considered.  If you resumbit a patch
that follows the GCS with a ChangeLog your chances of a speedy review
are much increased.

Brian