I can&#39;t reproduce the behavior on any of the less egregiously inlined functions. For everything else the running times are the same using either local packages or installed libraries. <br><br><div class="gmail_quote">On Tue, Jun 24, 2008 at 3:16 PM, Ian Lynagh &lt;<a href="mailto:igloo@earth.li">igloo@earth.li</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Tue, Jun 24, 2008 at 02:01:58PM -0700, Donald Bruce Stewart wrote:<br>

&gt; &gt;<br>
&gt; &gt; &nbsp; &nbsp;1) Library is installed via cabal.<br>
&gt; &gt; &nbsp; &nbsp;2) Library source lives in the same directory as the application, so that<br>
&gt; &gt; &nbsp; &nbsp;ghc --make Examples.hs also builds the library.<br>
&gt;<br>
&gt; That&#39;s compiling Examples with full access to the source though!<br>
&gt; So ghc has the entire source available.<br>
<br>
</div>That shouldn&#39;t make any difference. I suspect a flag difference is to<br>
blame - giving cabal build the -v flag will show which flags it is<br>
using.<br>
</blockquote><div><br>I&#39;ve taken all optimization flags out of the .cabal file. They don&#39;t have any effect. My understanding of things is this: (please correct if wrong) All functions have inline pragmas, and all are small (1 or 2 lines) so their definitions are all spewed into the .hi files. So in both scenarios (library vs local) GHC can &quot;see&quot; the whole library. Since every function is inlined, it doesn&#39;t matter what flags the library is compiled with. That compiled code will never be used so long as the application is compiled with optimization on.&nbsp; <br>
<br>Now the particulars of the situation are this: the function in question is inlined very deeply, it has many instance constraints, and during simplification the core blows up to _ridiculous_ sizes. (Compilation with -ddump-simpl is taking about 5-10 min.) I think I&#39;m pushing the compiler to unreasonable limits, and I think maybe something non-obvious is going on inside.<br>
<br>On the otherhand, pushing the compiler in this way gets me a 3x speedup, which is nothing to sneeze at. In the meantime I&#39;ll see what I can do to make this function (gaussian elimination) more amenable to simplification. The rest of the library works great.<br>
<br>Scott<br></div></div>