8.2.1 changes to iface/FlagChecker.hs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

8.2.1 changes to iface/FlagChecker.hs

Evan Laforge
My program uses the GHC API to provide a REPL, and upgrading to 8.2.1
broke that... well, just made it really slow.  Where it used to
quickly load the compiled files, it now wants to recompile everything
as bytecode which makes 1s startup time go to 1m.  The reason was it
now thinks flags have changed.  I tracked it down to changes in
FlagChecker.hs, documented with
https://ghc.haskell.org/trac/ghc/ticket/11798 and
https://ghc.haskell.org/trac/ghc/ticket/10923, which add -fhpc and -O
to the tracked flags.  -fhpc means loading tests in ghci can never
work, because ghci rejects the -fhpc flag, and likewise -O means ghci
can never load optimized files for the same reason.

It seems like the easiest solution might be to just have ghci not
reject -fhpc and -O.  Of course we could also revert those changes,
but they're justified in the trac tickets.

Of course this means I'm loading optimized code together with bytecode
compiled code and maybe that's a bad thing (or for tests, -fhpc with
non-hpc).  But I've been doing this for something like 7 years and
it's been fine.


Unrelatedly, I was hoping compiles would get faster, but they seem a
bit slower, from around 3m20s to around 4m :(  I can track down
per-file timing changes if it would be interesting to someone.

Also thanks to whoever put trac tickets in the comments, it makes it
really easy to find out why a change was made.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: 8.2.1 changes to iface/FlagChecker.hs

George Colpitts

On Thu, Aug 3, 2017 at 4:32 PM Evan Laforge <[hidden email]> wrote:
My program uses the GHC API to provide a REPL, and upgrading to 8.2.1
broke that... well, just made it really slow.  Where it used to
quickly load the compiled files, it now wants to recompile everything
as bytecode which makes 1s startup time go to 1m.  The reason was it
now thinks flags have changed.  I tracked it down to changes in
FlagChecker.hs, documented with
https://ghc.haskell.org/trac/ghc/ticket/11798 and
https://ghc.haskell.org/trac/ghc/ticket/10923, which add -fhpc and -O
to the tracked flags.  -fhpc means loading tests in ghci can never
work, because ghci rejects the -fhpc flag, and likewise -O means ghci
can never load optimized files for the same reason.

It seems like the easiest solution might be to just have ghci not
reject -fhpc and -O.  Of course we could also revert those changes,
but they're justified in the trac tickets.

Of course this means I'm loading optimized code together with bytecode
compiled code and maybe that's a bad thing (or for tests, -fhpc with
non-hpc).  But I've been doing this for something like 7 years and
it's been fine.


Unrelatedly, I was hoping compiles would get faster, but they seem a
bit slower, from around 3m20s to around 4m :(  I can track down
per-file timing changes if it would be interesting to someone.

Also thanks to whoever put trac tickets in the comments, it makes it
really easy to find out why a change was made.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: 8.2.1 changes to iface/FlagChecker.hs

Evan Laforge
Thanks, I added my two cents to the ticket.

On Thu, Aug 3, 2017 at 12:37 PM, George Colpitts
<[hidden email]> wrote:

> I reported this in https://ghc.haskell.org/trac/ghc/ticket/13604
>
> On Thu, Aug 3, 2017 at 4:32 PM Evan Laforge <[hidden email]> wrote:
>>
>> My program uses the GHC API to provide a REPL, and upgrading to 8.2.1
>> broke that... well, just made it really slow.  Where it used to
>> quickly load the compiled files, it now wants to recompile everything
>> as bytecode which makes 1s startup time go to 1m.  The reason was it
>> now thinks flags have changed.  I tracked it down to changes in
>> FlagChecker.hs, documented with
>> https://ghc.haskell.org/trac/ghc/ticket/11798 and
>> https://ghc.haskell.org/trac/ghc/ticket/10923, which add -fhpc and -O
>> to the tracked flags.  -fhpc means loading tests in ghci can never
>> work, because ghci rejects the -fhpc flag, and likewise -O means ghci
>> can never load optimized files for the same reason.
>>
>> It seems like the easiest solution might be to just have ghci not
>> reject -fhpc and -O.  Of course we could also revert those changes,
>> but they're justified in the trac tickets.
>>
>> Of course this means I'm loading optimized code together with bytecode
>> compiled code and maybe that's a bad thing (or for tests, -fhpc with
>> non-hpc).  But I've been doing this for something like 7 years and
>> it's been fine.
>>
>>
>> Unrelatedly, I was hoping compiles would get faster, but they seem a
>> bit slower, from around 3m20s to around 4m :(  I can track down
>> per-file timing changes if it would be interesting to someone.
>>
>> Also thanks to whoever put trac tickets in the comments, it makes it
>> really easy to find out why a change was made.
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users