Re: Initial compile time benchmarks

2016-04-01 Thread Ben Gamari
Ömer Sinan Ağacan writes: > I just benchmarked another set of packages, this time using -O2 optimized libs > + stage 2 (6ea42c7): > > https://gist.githubusercontent.com/osa1/b483216953e3b02c0c79f9e4c8f8f931/raw/64001a1bfb71c0c4441c07f9f195bf5629095a6f/gistfile1.txt > > For me the most surprising

Re: Initial compile time benchmarks

2016-03-31 Thread Ömer Sinan Ağacan
I just benchmarked another set of packages, this time using -O2 optimized libs + stage 2 (6ea42c7): https://gist.githubusercontent.com/osa1/b483216953e3b02c0c79f9e4c8f8f931/raw/64001a1bfb71c0c4441c07f9f195bf5629095a6f/gistfile1.txt For me the most surprising part is that CodeGen is sometimes taki

Re: Initial compile time benchmarks

2016-03-31 Thread Ömer Sinan Ağacan
Hi Joachim, That's GHC HEAD at the time with -O1 for stage 2 + libs. The way I generate the logs is: - I create a cabal sandbox and run `cabal exec zsh` to set up the env variables. - I install packages in that shell. - $ (cat .cabal-sandbox/logs/*.log | analyze-ghc-timings) > output I don

Re: Initial compile time benchmarks

2016-03-31 Thread Ömer Sinan Ağacan
Forgot to mention that I use `cabal install --ghc-options="-v3" -v3` to install the packages. 2016-03-31 12:00 GMT-04:00 Ömer Sinan Ağacan : > Hi Joachim, > > That's GHC HEAD at the time with -O1 for stage 2 + libs. > > The way I generate the logs is: > > - I create a cabal sandbox and run `cabal

Re: Initial compile time benchmarks

2016-03-31 Thread Joachim Breitner
Hi Ömer, thanks for the log. This is roughly GHC HEAD, right? I wanted to check for low-hanging fruit in “my” code, so I compiled Data.Reflection, where your tool reports 12% time spent in Call Arity.  But if I run it with profiling, it says 3.5% of time is spent in that pass, and if I run your

RE: Initial compile time benchmarks

2016-03-30 Thread Simon Peyton Jones
@haskell.org] On Behalf Of | Joachim Breitner | Sent: 30 March 2016 08:11 | To: ghc-devs@haskell.org | Subject: Re: Initial compile time benchmarks | | Hi, | | Am Dienstag, den 29.03.2016, 15:29 -0700 schrieb Edward Z. Yang: | > This ticket may be of interest: | > | > https://g

Re: Initial compile time benchmarks

2016-03-30 Thread Joachim Breitner
Hi, Am Dienstag, den 29.03.2016, 15:29 -0700 schrieb Edward Z. Yang: > This ticket may be of interest: > > https://ghc.haskell.org/trac/ghc/ticket/9630 > > Deriving costs a lot and we just need someone to figure out what's > going on. are you sure that deriving itself costs a lot? I would expec

Re: Initial compile time benchmarks

2016-03-29 Thread Edward Z. Yang
This ticket may be of interest: https://ghc.haskell.org/trac/ghc/ticket/9630 Deriving costs a lot and we just need someone to figure out what's going on. Edward Excerpts from Michael Sloan's message of 2016-03-29 15:23:50 -0700: > Great! Thanks for y'all putting effort towards performance. It r

Re: Initial compile time benchmarks

2016-03-29 Thread Michael Sloan
Great! Thanks for y'all putting effort towards performance. It really is crucial for developer productivity. In the particular case of haskell-src-exts, I found that removing many of the more complicated typeclasses from deriving (Data, Generics, etc) brought the compilation time way down. IIRC it

Re: Initial compile time benchmarks

2016-03-29 Thread Eric Seidel
Very cool! It would be nice to add build flags to the table (or at least optimization levels) as these probably differ across packages, and will certainly impact the numbers. I'd also be really interested to see a comparison of the timing data for -O0 and -O. I think the biggest impact for perfo