Inlining derived typeclass methods

Question

Haskell lets you derive typeclass instances, such as:

{-# LANGUAGE DeriveFunctor #-}  data Foo a = MakeFoo a a deriving (Functor) 

... but sometimes benchmarks show that performance improves if you manually implement the typeclass instance and annotate the type class method(s) with INLINE, like this:

data Foo a = MakeFoo a a  instance Functor Foo where     fmap f (MakeFoo x y) = MakeFoo (f x) (f y)     {-# INLINE fmap #-} 

Is there a way to get the best of both worlds? In other words, is there a way to derive the typeclass instance and also annotate the derived typeclass methods with INLINE?

Answer 1

Though you cannot "reopen" instances in Haskell like you could with classes in dynamic languages, there are ways to ensure that functions will be aggressively inlined whenever possible by passing certain flags to GHC.

-fspecialise-aggressively removes the restrictions about which functions are specialisable. Any overloaded function will be specialised with this flag. This can potentially create lots of additional code.

-fexpose-all-unfoldings will include the (optimised) unfoldings of all functions in interface files so that they can be inlined and specialised across modules.

Using these two flags in conjunction will have nearly the same effect as marking every definition as INLINABLE apart from the fact that the unfoldings for INLINABLE definitions are not optimised.

(Source: https://wiki.haskell.org/Inlining_and_Specialisation#Which_flags_can_I_use_to_control_the_simplifier_and_inliner.3F)

These options will allow the GHC compiler to inline fmap. The -fexpose-all-unfoldings option, in particular, allows the compiler to expose the internals of Data.Functor to the rest of the program for inlining purposes (and it seems to provide the largest performance benefit). Here's a quick & dumb benchmark I threw together:

functor.hs contains this code:

{-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE Strict #-}  data Foo a = MakeFoo a a deriving (Functor)  one_fmap foo = fmap (+1) foo  main = sequence (fmap (\n -> return $ one_fmap $ MakeFoo n n) [1..10000000]) 

Compiled with no arguments:

$ time ./functor   real    0m4.036s user    0m3.550s sys 0m0.485s 

Compiled with -fexpose-all-unfoldings:

$ time ./functor  real    0m3.662s user    0m3.258s sys 0m0.404s 

Here's the .prof file from this compile, to show that the call to fmap is indeed getting inlined:

    Sun Oct  7 00:06 2018 Time and Allocation Profiling Report  (Final)         functor +RTS -p -RTS      total time  =        1.95 secs   (1952 ticks @ 1000 us, 1 processor)     total alloc = 4,240,039,224 bytes  (excludes profiling overheads)  COST CENTRE MODULE SRC              %time %alloc  CAF         Main   <entire-module>  100.0  100.0                                                                        individual      inherited COST CENTRE MODULE                SRC             no.     entries  %time %alloc   %time %alloc  MAIN        MAIN                  <built-in>       44          0    0.0    0.0   100.0  100.0  CAF        Main                  <entire-module>  87          0  100.0  100.0   100.0  100.0  CAF        GHC.IO.Handle.FD      <entire-module>  84          0    0.0    0.0     0.0    0.0  CAF        GHC.IO.Encoding       <entire-module>  77          0    0.0    0.0     0.0    0.0  CAF        GHC.Conc.Signal       <entire-module>  71          0    0.0    0.0     0.0    0.0  CAF        GHC.IO.Encoding.Iconv <entire-module>  58          0    0.0    0.0     0.0    0.0 

Compiled with -fspecialise-aggressively:

$ time ./functor  real    0m3.761s user    0m3.300s sys 0m0.460s 

Compiled with both flags:

$ time ./functor  real    0m3.665s user    0m3.213s sys 0m0.452s 

These little benchmarks are by no means representative of what the performance (or filesize) will like in real code, but it definitely shows that you can force the GHC compiler to inline fmap (and that it really can have non-negligible effects on performance).