search for: 15tgiyphoatiodxisrcabg5iigtbfxatc

...ile the difference observed but did not found any visible bottlenecks. We seem just become a bit slower everywhere in the linker, I believe this is caused by natural reasons: more sections, larger inputs -> slower result. (I shared both reproduce sets used here: https://drive.google.com/open?id=15tGIypHOATiodxISRCAbg5iiGTBFXAtc).? Best regards, George | Developer | Access Softek, Inc ________________________________ От: George Rimar Отправлено: 28 марта 2018 г. 18:44 Кому: bd1976 llvm Копия: Cary Coutant; llvm-dev at lists.llvm.org; nd at arm.com; llvm-dev-request at lists.llvm.org Тема: Re: [llvm-dev] [RFC] Making .eh...

>@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

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