ghci 7.4.1 no longer loading .o files?

[Evan Laforge]

On Mon, Feb 27, 2012 at 9:56 AM, Yitzchak Gale <gale at sefer.org> wrote:
> Evan Laforge wrote:
>>>> Is there something that changed in 7.4.1 that would cause it to decide
>>>> to interpret .hs files instead of loading their .o files?  E.g.:
>
> Brandon Allbery wrote:
>>> I thought this was deliberate because the debugger won't work with object
>>> files?
>
>> Oh I hope not.  I almost never use the debugger, and it's so much
>> slower to re-interpret all those modules.
>
> I am surprised about this complaint. I have never noticed any
> significant delay for re-interpreting, even when working on
> projects that are quite large, with tens of thousands of LOC.

Really really?  I'm even more surprised!  Maybe you have a really fast computer?

I just tested a module moderately high in the app, which drags in 134
modules (out of 300 or so).  When it re-interprets them all, it takes
around 16 seconds.  When it can load them all from .o files, it's
around 1 second.  Usually what happens is I'll be testing, and some
test will fail.  If I edit some module and reload only the dependent
modules get reloaded, which is usually ok.  But if I switch to another
module with :l instead of :r, or if there was a particularly bad
syntax error, it will want to reload everything.  There's a big
difference between waiting under a second to try a change or
experiment with a function and waiting 16 seconds!  It doesn't feel
interactive anymore.  This is on a new MacBook Pro with an SSD, which
is a relatively high end laptop.

The other thing is that I use hint to insert a REPL into the app.
This may be a result of me using hint wrong, or how hint uses the ghc
API, but every expression apparently does the equivalent of a complete
reload.  It's ok when each expression takes about 1s, but not when
they all take 16s each!  I need to to some research here to figure out
if I can implement something more ghci-like, specifically :reload.

> I have always found the behavior of using .o files by
> default surprising and annoying. The "i" in GHCi stands
> for "interactive". I expect work in GHCi to be as interactive
> as possible in every way, including having access to the
> debugger. I expect performance to be similar to the usual
> performance of interpreter shells in any language; I don't
> mind if it doesn't match the speed of compiled Haskell.

Oh, I don't care so much about the speed of the code being executed,
it's how long it takes that code to load into ghci.

> GHCi is headed in that direction in many ways, and I
> think that's great. I don't think more flags should be
> "excluded from the fingerprint" by default if that would
> detract in any way from the interactive experience.
> In particular, it is especially important for
> -XNoMonomorphismRestriction to be the default in
> GHCi.

Yeah, I used to have that on for ghci, but it in 7.4.1 it makes it not
load the .o files.  I agree it's the right choice for ghci, but to me
it's not worth the no-longer-interactive caveat it comes with.

One other point about the fingerprint thing, is that it also affects
--make.  That can be the difference between a 1m build and a 15m
build.  I'm insulated from this because I don't use --make anymore,
but it's still very convenient for pure haskell projects.  Not to
mention cabal uses it.

Of course getting mysterious link errors due to inconsistent flags can
waste much more than 15m of debugging time, so we should definitely
avoid those.  But I think the current settings are too conservative.

> See also these tickets:
>
> http://hackage.haskell.org/trac/ghc/ticket/3217
> http://hackage.haskell.org/trac/ghc/ticket/3202

Ya, I agree with both of those tickets, but I think they're orthogonal.