Summary of containers patches

Don Stewart dons at galois.com
Fri Sep 24 01:19:00 EDT 2010


ivan.miljenovic:
> On 24 September 2010 14:58, Don Stewart <dons at galois.com> wrote:
> > ivan.miljenovic:
> >> On 24 September 2010 14:36, Michael Snoyman <michael at snoyman.com> wrote:
> >> > On Fri, Sep 24, 2010 at 6:26 AM, Don Stewart <dons at galois.com> wrote:
> >> >> Perhaps a containers-inline fork is needed, for those who still need the speed.
> >> >
> >> > Would it be possible to use CPP to turn the INLINE flags into a
> >> > compile-time argument, ie:
> >> >
> >> > #ifdef INLINE
> >> > {-# INLINE #-}
> >> > #endif
> >>
> >> Since containers ships with GHC, wouldn't this then require an extra
> >> flag being used when building GHC to enable this?
> >>
> >> And then to use it, you'd have to build your own GHC rather than using
> >> a pre-built binary like just about everyone does...
> >>
> >> > I'd hate to start seeing incompatible Data.Map.Maps floating around.
> >>
> >> Agreed.  At the very least if there was a fork it would presumably
> >> have to be in a different module namespace to avoid namespace
> >> collisions, which would make the incompatability obvious.
> >
> > We're talking about a 3% increase in the size of the Map, a 2% size in
> > the Map.hs benchmark binary, right?
> >
> > For a 50% increase in Map function performance.
> 
> I'm not arguing against it; I'm just arguing against whether or not a
> fork would be beneficial.

Indeed. I'm surprised we're actually considering rolling back Map
specialization -- and the big improvements that gives us -- for what
seems to be a small percent in binary size.

Recall Johan's recent user survey: people are asking for more
performance, and more reliable performance, not shaving binary sizes.
 
-- Don


More information about the Libraries mailing list