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

Peter Collingbourne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 9 13:38:14 PST 2016


pcc added a comment.

In https://reviews.llvm.org/D21166#618607, @ruiu wrote:

> I think I want to get this in to close the architectural difference between COFF and ELF, and I like it removes the half-baked parallel file parsing.
>
> > 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
>
>
>
>   #include <sys/time.h>
>   
>   static uint64_t microsec(struct timespec Time) {
>     return Time.tv_sec * 1000000 + (Time.tv_nsec / 1000);
>   }
>  
>   void elf::log2(const Twine &Msg) {
>     static uint64_t Start = 0;
>     struct timespec Time;
>     clock_gettime(CLOCK_MONOTONIC, &Time);
>     if (Start == 0)
>       Start = microsec(Time);
>     llvm::errs() << (microsec(Time) - Start) << " " << Msg << "\n";
>   }
>   
>
> I often add this piece of code to measure time of each pass. This is hacky but still better than `time` command. Did you try to measure this patch on Windows?


Yes, and I'm still seeing the regression on Windows. The MSVC profiler tells me that I'm spending a lot of time creating memory maps for files, so I'm wondering whether memory map performance on Windows is the root cause of the very different performance results as compared to Linux (maybe this patch somehow causes us to open files repeatedly or something, I don't know). I'm still investigating, but I think I'd be fine with landing this in parallel with the investigation.


https://reviews.llvm.org/D21166





More information about the llvm-commits mailing list