Stop using "Int" for microsecond delays in "base"
wren ng thornton
wren at freegeek.org
Thu Mar 31 10:55:41 CEST 2011
On 3/30/11 2:00 PM, Johan Tibell wrote:
> On Wed, Mar 30, 2011 at 7:56 PM, Evan Laforge<qdunkan at gmail.com> 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
More information about the Libraries