containers: to be or not to be (strict, in this case)?
ml at isaac.cedarswampstudios.org
Wed Mar 4 19:45:18 EST 2009
Claus Reinke wrote:
> The idea being to abstract over every application of the container
> constructors to the element type, then to supply either strict or
> non-strict application. Ultimately, one might prefer a
> type-constructor-based abstraction instead, to gain additional performance,
> but this should be at least as good as the current situation (perhaps with
> an INLINE on the parameterised versions), without the duplication.
the "Box" approach is attractive but performance-unoptimal...
we can try that type-constructor stuff. Is it like:
data IntMap_ strictness a = ... --(not including "strictness" values)
class Strictness s where ...
well, it turns out to have similar performance issues to passing around ($) or
($!), except they'd be resolved in the compiler by SPECIALIZE rather than
INLINE stuff (I guess).
Anyway, the compiler basically can't optimize away Box at all.
And changing the strictness of a Box-based IntMap, would be linear time rather
than constant (zero) time for a purely newtype-based solution (if indeed they
need to be separate types, rather than just different modules with different
implementations of e.g. insertWith for the same data-type).
More information about the Libraries