[PATCH] D21166: [wip] COFF: New symbol table design.

Peter Collingbourne via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 8 21:57:51 PST 2016


So now that I'm able to link chrome_child.dll on Linux it turns out that I
get very different results with "perf stat":

Before (median of 5 runs): 11.623297415 seconds time elapsed
After: 8.123567205 seconds time elapsed

At this point I'm not really sure why I was getting different results on
Windows before, but it may have been a fluke or a side effect of how I was
taking measurements (as I recall I was using the Cygwin "time" utility --
as you might guess I don't really know the best way to measure this sort of
thing on Windows -- suggestions welcome).

I uploaded a new version of the patch to phab if you'd like to take a look.

Peter

On Thu, Jun 9, 2016 at 6:19 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:

> I still don't understand the cause of the regression. As I mentioned, I
> still see a regression if I disable parallel object file parsing in the
> existing code (by replacing the code starting at COFF/SymbolTable.cpp:28
> with just "std::launch Policy = std::launch::deferred;") so it might not
> have anything to do with parallel object file parsing.
>
> I would also like to see whether this has something to do with the host
> OS. I am working on a patch that adds a /reproduce flag to the COFF linker
> to make it easier to measure performance on a Linux host.
>
> Peter
>
> On Thu, Jun 9, 2016 at 11:48 AM, Rui Ueyama <ruiu at google.com> wrote:
>
>> ruiu added a comment.
>>
>> It's interesting that this patch regresses performance even though this
>> approach proved to be effective for the ELF linker. Does it mean the
>> parallel object file parsing is effective for COFF? If so, it may indicate
>> a possible optimization we can make for the ELF linker.
>>
>>
>> http://reviews.llvm.org/D21166
>>
>>
>>
>>
>
>
> --
> --
> Peter
>



-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161208/5e23a913/attachment.html>


More information about the llvm-commits mailing list