Summary of containers patches
Thomas Schilling
nominolo at googlemail.com
Fri Sep 24 04:41:16 EDT 2010
On 24 September 2010 06:19, Don Stewart <dons at galois.com> wrote:
> 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.
That would be true if we actually had numbers on how the changes
affect programs in the wild. Your performance claims are based on
micro benchmarks. Who knows whether code bloat will offset the
performance gains on any "real" benchmark. One GHC object file
*tripled* in size, for example. This is probably because it's simply
wrapping Map, but it's still not clear how it may affect other
programs.
All I'm saying, be careful with these numbers.
/ Thomas
--
Push the envelope. Watch it bend.
More information about the Libraries
mailing list