Displaying 3 results from an estimated 3 matches for "2464ms".
2018 Apr 30
0
[RFC] Making .eh_frame more linker-friendly
...em was built with vanilla clang and one with clang+https://reviews.llvm.org/D40352 patch applied.
As a result, the second set of object contained multiple .eh_frames (for each text section),
and the first set was just regular set.
Link times after 200 runs were:
1) ~2332ms for the regular set.
2) ~2464ms for "D40352" set.
The difference is about 6%. Does not look too scary as ~10% for clang link time I had earlier actually.
Note that I did not apply any other patches than D40352. For example, there is a draft patch for linker
that could use the benefit of objects with multiple .eh_frames...
2018 Mar 28
0
[RFC] Making .eh_frame more linker-friendly
>@Grimar: Did you do any profiling of the code? Were the slowdowns
>you were seeing fundamental (i.e. due to IO) or could a more optimal
>implementation reduce the slowdown? Did you do any end to end
>timings for compilation + link time?
No, as far I remember I did not profile this. All results I had were about linker
timing for linking clang (posted in this thread).
I think the
2018 Mar 28
2
[RFC] Making .eh_frame more linker-friendly
I am very interested in reviving this.
Did anyone get any further with these ideas?
@Grimar: Did you do any profiling of the code? Were the slowdowns
you were seeing fundamental (i.e. due to IO) or could a more optimal
implementation reduce the slowdown? Did you do any end to end
timings for compilation + link time?
The same issues arise for all metadata sections:
.eh_frame