Stop using "Int" for microsecond delays in "base"

Bas van Dijk v.dijk.bas at
Thu Mar 31 12:08:22 CEST 2011

On 31 March 2011 10:55, wren ng thornton <wren at> wrote:
> On 3/30/11 2:00 PM, Johan Tibell wrote:
>> On Wed, Mar 30, 2011 at 7:56 PM, Evan Laforge<qdunkan at>  wrote:
>>> It's good for big data structures since it can be unpacked into the
>>> constructor.  I've seen space usage go down by 1/3 after an Integer ->
>>> Int switch.  Integer is a sum type so there's an extra two words of
>>> overhead (if not mistaken, one for the tag, and one for the
>>> indirection since it can't unpack).
>> Yes. Integer is terrible for performance.
> This makes me wonder, though, whether it'd be worthwhile to:
> (A) make a special case allowing unpacking of Integers (e.g., by storing the
> constructor tag adjacent to the payload, ala PiSigma), or
> (B) to simplify the implementation to
>    data Integer = J# Int# ByteArray#
> where the current (S# (x::Int#)) is implemented by (J# x nullPtr) or
> whatever the equivalent is for ByteArray#s ---Hackage doesn't want to show
> me the source for what a ByteArray# actually is implemented as...
> I could see the PiSigma implementation of A causing a lot of ruckus
> throughout the runtime, which would be a good reason to rule that out.
> But I can't see why B hasn't been done ---even if just as an implementation
> of A! It increases the memory footprint for Int-sized Integers, which is
> unfortunate, but the check for null should be no more expensive than the
> case match, and it opens the way for unpacking and related optimizations
> (which would offset or reverse the memory footprint differences).
> --
> Live well,
> ~wren
> _______________________________________________
> Libraries mailing list
> Libraries at

You may also want to read section 3.3 of:
(note though that this document is more than 2 years old)


More information about the Libraries mailing list