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

On 3/30/11 2:00 PM, Johan Tibell wrote:

On Wed, Mar 30, 2011 at 7:56 PM, Evan Laforge 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