ByteArray# is a GHC primitive. There is no Haskell code for it unless you want to look at the compiler implementation. It also doesn't have a null-like value, but I guess you could use an empty one?

Dan

On Thu, Mar 31, 2011 at 4:55 AM, wren ng thornton <wren@freegeek.org> wrote:
On 3/30/11 2:00 PM, Johan Tibell wrote:
On Wed, Mar 30, 2011 at 7:56 PM, Evan Laforge<qdunkan@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


_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries