<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 18, 2017 at 1:23 PM, Saurabh Nanda <span dir="ltr"><<a href="mailto:saurabhnanda@gmail.com" target="_blank">saurabhnanda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>We're trying to optimise the way lenses are built and imported in our project (there are 500+ of them!) . In the simplified version that I have presented below, whenever a new HasX class is added to the LensClasses module, both User & Main end up getting recompiled even though they have nothing to do with the newly added type-class. I've read and re-read "Recompilation Avoidance" [1], but haven't been able to figure out why this would be happening.</div></div></blockquote></div><div><br></div><div>Because it is part of the external interface for dependencies of those modules and therefore triggers both an API change (which here has no effect) and an ABI change because internals of a module can leak out via .hi file exposure for cross-module inlining. There is no way to guard against that last, and avoiding it would usually be even more expensive than just treating the entire .hi as a dependency that changed (the dependency graph would *explode* if you had to track dependencies per possible inlining).</div><div><br></div><div>And no, you do not want to defeat inlining, *especially* with lens. Performance will utterly tank.</div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</div></div>