[GHC] #13344: Core string literal patch regresses compiler performance considerably
GHC
ghc-devs at haskell.org
Thu Mar 2 23:12:53 UTC 2017
#13344: Core string literal patch regresses compiler performance considerably
-------------------------------------+-------------------------------------
Reporter: bgamari | Owner: bgamari
Type: bug | Status: new
Priority: high | Milestone: 8.2.1
Component: Compiler | Version: 8.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Compile-time | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by simonpj):
I'm all for making interface-file deserialisation cheaper.
But I don't feel that we have a well-characterised problem. ''What
exactly is the problem we are trying to solve here?''
Is it ONLY that
{{{
x :: Addr#
x = "foo"#
y :: T
y = K x
}}}
is more expensive than
{{{
y :: T
y = K "foo"#
}}}
And if it is more expensive, how much more expensive? And does that cost
come from simplifying, spitting out an interface file, code generation,
reading in an interface file?
I don't think there is much to do with strings here. The same will happen
for
{{{
x = [True, False, True, ..., True]
}}}
Perhaps we just don't want to expose the unfolding for a top level
constructor. That would be a bit less good on optimisation, but perhaps
not a lot. We could measure it.
I feel as if we are at risk of taking actions without data to guide them.
I'd love to have data.
Simon
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13344#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list