I can'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.
On Tue, Jun 24, 2008 at 3:16 PM, Ian Lynagh
1) Library is installed via cabal. 2) Library source lives in the same directory as the application, so
On Tue, Jun 24, 2008 at 02:01:58PM -0700, Donald Bruce Stewart wrote: that
ghc --make Examples.hs also builds the library.
That's compiling Examples with full access to the source though! So ghc has the entire source available.
That shouldn't make any difference. I suspect a flag difference is to blame - giving cabal build the -v flag will show which flags it is using.
I've taken all optimization flags out of the .cabal file. They don'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 "see" the whole library. Since every function is inlined, it doesn'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. 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'm pushing the compiler to unreasonable limits, and I think maybe something non-obvious is going on inside. On the otherhand, pushing the compiler in this way gets me a 3x speedup, which is nothing to sneeze at. In the meantime I'll see what I can do to make this function (gaussian elimination) more amenable to simplification. The rest of the library works great. Scott