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

[wren ng thornton]

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 
footprint differences).

-- 
Live well,
~wren