search for: 2464ms

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