[Haskell-cafe] Strange type behavior in GHCi 6.4.2

[Grady Lemoine]

That's interesting.  I suppose it makes sense -- for polymorphism that
doesn't involve typeclasses, nothing is assumed about what kind of
data you have, so there's nothing you can do with it that isn't
generic to all data types.  I was wondering if the compiler would
automatically generate specialized code for certain concrete instances
of a typeclass (Double) in addition to generic code for an arbitrary
member of the typeclass (Floating a), and it sounds like I may or may
not get that in the way I want.  I suppose there may have to be some
slowdown -- if the compiler specializes every piece of code for every
instance of a typeclass it might encounter, it could bloat the
executable beyond all reason.  I'll have to do some tests to see if I
notice an effect in practice.

Thank you,

--Grady Lemoine

On 12/28/06, Kirsten Chevalier <catamorphism at gmail.com> wrote:
> On 12/28/06, Grady Lemoine <grady.lemoine at gmail.com> wrote:
> >
> > One question I have, though, for anyone on the list who knows the
> > answer -- if I give a function a polymorphic type signature, can it
> > affect performance?  That is, if I write two functions with the same
> > definitions but different user-specified type signatures,
> >
> > foo1 :: (Floating a) => a -> a
> > foo1 = ...
> >
> > and
> >
> > foo2 :: Double -> Double
> > foo2 = ...
> >
> > when I apply foo1 to a Double, will the compiler (GHC, specifically)
> > generate code that is just as efficient as if I used foo2?
> >
>
> As with so many things, the answer is "it depends". The simple answer
> to "if I give a function a polymorphic type signature, can it affect
> performance?" is "no, because type information is erased before code
> generation". However, if by "polymorphic type signatures" you mean
> ones involving class-based overloading, like the ones you wrote, then
> the answer is "maybe" -- functions that have classes involved in their
> types are desugared by the compiler into functions that take extra
> "dictionary" arguments, which can make performance worse. GHC does
> "specialization" to try to negate some of the performance impact of
> this, but it doesn't always do what you want it to. The best thing to
> do is to make sure you compile your code with -O2 and if profiling
> seems to imply that overloaded functions are causing you bottlenecks,
> seek help on this list or on Haskell IRC (and there should be a pretty
> good body of previous discussion on the subject in the list archives).
>
> Cheers,
> Kirsten
>
> --
> Kirsten Chevalier* chevalier at alum.wellesley.edu *Often in error, never in doubt
> "I eat too much / I laugh too long / I like too much of you when I'm
> gone." -- Ani DiFranco
>