Ticket #7249 (closed bug: fixed)

Opened 8 months ago

Last modified 7 months ago

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 Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

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

  Changed 8 months 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.

  Changed 7 months 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

  Changed 7 months ago by igloo

(that is with SplitObjs = YES)

follow-up: ↓ 5   Changed 7 months 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?

in reply to: ↑ 4   Changed 7 months ago by igloo

  • status changed from new to closed
  • resolution set to fixed

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.

follow-up: ↓ 7   Changed 7 months 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.

in reply to: ↑ 6   Changed 7 months 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.