<div dir="ltr">If this is faster than -print-after-all we may actually consider pushing that in the code base then? (after diligent code review of course)<div><br></div><div>Note that it uses the same printing method as -print-after-all:</div><div>- create a pass of the same pass kind as the pass we just ran</div><div>- use Module::print(raw_ostream) to print (except -print-after-all only print the concerned part and into stdout)</div><div><br></div><div>If there is improvement to be done to print-after-all it might also improve git-commit-after-all. (unless that only improve speed when printing constructs smaller than module)</div><div><br></div><div>In any case, it is, to me, much more usable (and extensible) than -print-after-all. But requires git to be in PATH (I'm curious if that works on Windows).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 15, 2018 at 1:35 PM, Daniel Sanders <span dir="ltr"><<a href="mailto:daniel_l_sanders@apple.com" target="_blank">daniel_l_sanders@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Does <a href="https://reviews.llvm.org/D44132" target="_blank">https://reviews.llvm.org/<wbr>D44132</a> help at all?<div><div class="h5"><br><div><br><blockquote type="cite"><div>On 15 Mar 2018, at 09:16, Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_12165154445603995Apple-interchange-newline"><div>
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><p>The most likely answer is that the printer used by
      print-after-all is slow.  I know there were some changes made
      around passing in some form of state cache (metadata related?) and
      that running printers without doing so work, but are dog slow.  I
      suspect the print-after-all support was never updated.  Look at
      what we do for the normal IR emission "-S" and see if
      print-after-all is out of sync.  <br>
    </p><p>Philip<br>
    </p>
    <br>
    <div class="m_12165154445603995moz-cite-prefix">On 03/15/2018 08:45 AM, Alexandre
      Isoard via llvm-dev wrote:<br>
    </div>
    <blockquote type="cite">Huh.
      Great! 😁
      <div><br>
      </div>
      <div>I don't believe my poor excuse from earlier (else we should
        map all pipes into files!), but I'm curious why we spend less
        time in system mode when going through file than pipe. Maybe
        /dev/null is not as efficient as we might think? I can't believe
        I'm saying that...<br>
        <br>
        <div class="gmail_quote">
          <div dir="ltr">On Thu, Mar 15, 2018, 08:25 Fedor Sergeev <<a href="mailto:fedor.sergeev@azul.com" target="_blank">fedor.sergeev@azul.com</a>>
            wrote:</div>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            Well, git by itself is so focused on performance, so its not
            surprising<br>
            to me that even using git add/git commit does not cause<br>
            performance penalties.<br>
          </blockquote>
        </div>
      </div>
      <div><br>
      </div>
      <div>Sure, but still, I write more stuff (entire module) into a
        slower destination (file). Even ignoring git execution time it's
        counter intuitive.</div>
      <div><br>
      </div>
      <div>The only difference is that while I write more, it overwrite
        itself continuously, instead of being a long linear steam. I was
        thinking of mmap the file instead of going through our
        raw_stream, but maybe that's unnecessary then...</div>
      <div>
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          </blockquote>
        </div>
      </div>
      <br>
      <fieldset class="m_12165154445603995mimeAttachmentHeader"></fieldset>
      <br>
      <pre>______________________________<wbr>_________________
LLVM Developers mailing list
<a class="m_12165154445603995moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_12165154445603995moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
    <br>
  </div>

______________________________<wbr>_________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><b>Alexandre Isoard</b><br></div></div>
</div>