<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=koi8-r">
<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p></p>
<div><span style="font-size: 12pt;">I performed additional benchmarking today and also profiled this. </span><br>
</div>
<div>Previously I tried to link clang. I decided to take something much larger today. </div>
<div>So what I did was: took chromium sources and built 2 sets of objects. </div>
<div>One of them was built with vanilla clang and one with clang+https://reviews.llvm.org/D40352 patch applied.</div>
<div>As a result, the second set of object contained multiple .eh_frames (for each text section),</div>
<div>and the first set was just regular set.</div>
<div><br>
</div>
<div>Link times after 200 runs were:</div>
<div>1) ~2332ms for the regular set.<br>
</div>
<div>2) ~2464ms for "D40352" set.</div>
<div><br>
</div>
<div>The difference is about 6%. Does not look too scary as ~10% for clang link time I had earlier actually.</div>
<div>Note that I did not apply any other patches than D40352. For example, there is a draft patch for linker</div>
<div>that could use the benefit of objects with multiple .eh_frames to significantly simplify and even slightly</div>
<div>improve the -gc-sections implementation: https://reviews.llvm.org/D40484.</div>
<div>It could save some time for the case with GC probably.</div>
<div><br>
</div>
<div>Also, I tried to profile the difference observed but did not found any visible bottlenecks.</div>
<div>We seem just become a bit slower everywhere in the linker, I believe this is caused by natural</div>
<div>reasons: more sections, larger inputs -> slower result.</div>
<div><br>
</div>
<div>(I shared both reproduce sets used here: https://drive.google.com/open?id=15tGIypHOATiodxISRCAbg5iiGTBFXAtc).<br>
</div>
<p><br>
</p>
<p><br>
</p>
<div id="Signature">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div class="BodyFragment"><font size="2">
<div class="PlainText">Best regards,<br>
George | Developer | <span style="background-color:rgb(255,255,255); color:rgb(33,33,33); font-family:Calibri,sans-serif; font-size:13.3333px">Access Softek, Inc</span></div>
</font></div>
</div>
</div>
<div dir="ltr" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>От:</b> George Rimar<br>
<b>Отправлено:</b> 28 марта 2018 г. 18:44<br>
<b>Кому:</b> bd1976 llvm<br>
<b>Копия:</b> Cary Coutant; llvm-dev@lists.llvm.org; nd@arm.com; llvm-dev-request@lists.llvm.org<br>
<b>Тема:</b> Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly</font>
<div> </div>
</div>
<div>
<p><span style="font-family:Calibri,sans-serif; font-size:11pt; color:rgb(34,34,34)">>@Grimar: Did you do any profiling of the code? Were the slowdowns</span><br>
</p>
<div style="color:rgb(33,33,33)">
<div>
<div dir="ltr">
<div dir="ltr" style="color:rgb(34,34,34); font-family:arial,sans-serif; font-size:small; font-style:normal; font-weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; background-color:rgb(255,255,255)">
<p class="gmail-m_6978494689053410199gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
</p>
<p class="gmail-m_6978494689053410199gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
>you were seeing fundamental (i.e. due to IO) or could a more optimal</p>
<p class="gmail-m_6978494689053410199gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
>implementation reduce the slowdown? Did you do any end to end</p>
<p class="gmail-m_6978494689053410199gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
>timings for compilation + link time?</p>
<p class="gmail-m_6978494689053410199gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
<span><br>
</span></p>
<p class="gmail-m_6978494689053410199gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
</p>
<div>No, as far I remember I did not profile this. All results I had were about linker</div>
<div>timing for linking clang (posted in this thread).<br>
</div>
<div><br>
</div>
<div></div>
<div>
<div>I think the slowdown is natural. The more input sections we have the slower we are.</div>
<div>Since LLD is very fast by nature, honestly I do not really believe there is a huge</div>
<div>chance to significantly boost the observed ~12(?) percents slowdown.<br>
</div>
<div>Otherwise, that would probably be done earlier for the common case.<br>
</div>
<br>
</div>
<p class="gmail-m_6978494689053410199gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
<span>George.</span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>