Could you please measure the slowdown?  It'd help evaluate this decision.<br><br>On Wednesday, May 11, 2016, Eric Niebler <<a href="mailto:eniebler@boost.org">eniebler@boost.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">eric_niebler added a comment.<br>
<br>
> Can you split the functionality that gets the RealPath into a new function (something like llvm::sys::fs::canonical() or llvm::sys::fs::realpath()) and make openFileForRead calls it?<br>
<br>
>  [...]<br>
<br>
>  This is going to be useful for a bunch of other client in clang that are now obtaining realpath in a adhoc/slow ways.<br>
<br>
<br>
I hesitate to do that. The code in `openFileForRead` is less reusable than it appears. It prefers speed over correctness since opening files for reading is a hot path. If we make it a separate dedicated API, clients will have a reasonable expectation that it returns the correct results. Making it correct necessarily means making it slow, which means it would no longer be useable in `openFileForRead`.<br>
<br>
<br>
<a href="http://reviews.llvm.org/D19842" target="_blank">http://reviews.llvm.org/D19842</a><br>
<br>
<br>
<br>
</blockquote>