Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#7249 closed bug (fixed)

ghc no longer needs to build HS*.o ghci library files

Reported by: juhpetersen Owned by: igloo
Priority: normal Milestone:
Component: Build System Version: 7.6.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

I believe that ghci libraries files (HS*.o) are now redundant (and Cabal no longer builds them at least in trunk) so I think it would be good to stop ghc building them also now.

I didn't try hard but didn't work out yet how to do this in the ghc build system - patching Cabal didn't seem to be sufficient.

Change History (7)

comment:1 Changed 2 years ago by simonmar

  • difficulty set to Unknown

I think we're concerned that it will be slow to load the .a file when it was built with -split-objs, so someone should measure that.

comment:2 Changed 2 years ago by igloo

On OSX/64, with HSbase-4.6.0.0.o:

$ time echo ":q" | inplace/bin/ghc-stage2 --interactive
GHCi, version 7.7.20121009: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> Leaving GHCi.

real    0m0.151s
user    0m0.123s
sys     0m0.027s

and without:

$ time echo ":q" | inplace/bin/ghc-stage2 --interactive
GHCi, version 7.7.20121009: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> Leaving GHCi.

real    0m0.267s
user    0m0.202s
sys     0m0.059s

comment:3 Changed 2 years ago by igloo

(that is with SplitObjs = YES)

comment:4 follow-up: Changed 2 years ago by simonmar

  • Owner set to igloo

On platforms where we're switching to a dynamically-linked GHCi this won't be an issue. I suggest that we continue to ship HSbase.o on other platforms for the time being, since I'd rather not have that extra startup delay for runhaskell scripts and suchlike.

Ian - it looks like we can skip building the HSlib.o files when DYNAMIC_BY_DEFAULT==YES, could you do that?

comment:5 in reply to: ↑ 4 Changed 2 years ago by igloo

  • Resolution set to fixed
  • Status changed from new to closed

Replying to simonmar:

Ian - it looks like we can skip building the HSlib.o files when DYNAMIC_BY_DEFAULT==YES, could you do that?

Done.

comment:6 follow-up: Changed 2 years ago by juhpetersen

I see thanks. I hadn't realised that split-objs would affect load time of .a files.

Testing in the same way on 64bit Fedora 17 ghc-7.0.4 and Fedora 18 ghc-7.4.1 (at Beta time)
I see that ghci startup loading libHSbase.a (built with split-objs) is taking about twice as long as HSbase.o. Though it does cut down the size of library packages quite a bit.

In fact Fedora 18 is going to ship without any HS*.o files packaged:
we will see how that goes - reverting the change to ghc
is pretty easy of course... For projects with many dependent packages
I guess it will slow down ghci startup for debugging, etc a bit.
So I will probably turn on ghci libs again in Fedora 19 at least.

comment:7 in reply to: ↑ 6 Changed 2 years ago by juhpetersen

For projects with many dependent packages
I guess it will slow down ghci startup for debugging, etc a bit.

Ah, since Cabal doesn't enable split-objs by default,
normally this only affects ghc's libs.

Then I think I will turn on ghci libs again also for Fedora 18 ghc.

Note: See TracTickets for help on using tickets.