Maurício wrote:
But why would you want that? I understand the only
situation when talking about number of bytes
makes sense is when you are using Foreign and
Ptr. Besides that, you can only guess the amount
of memory you need to deal with your data (taking
laziness, GC etc. into account).
Because I'm using both Ptr and Foreign? ;)
See my recent announcement for bytestring-trie. One of the optimizations
I'm working on is to read off a full natural word at a time, instead of
just one byte. To do this properly I need to detect the word size so
that I don't accidentally read garbage off the end of the ByteString
when there's less than a natural word left.
Detecting endianness is similar because it determines how to interpret
that word as if it were an array of bytes, which is needed to get the
correct behavior when interpreting the word as a bit-vector for trieing.
That is, if you only read the "first" two bytes on a big-endian machine,
then you're skipping the 4/6/? bytes which are actually at the beginning
of the bytestring.
I'm not sure how important physical endianness of bytes within a word
is. For IntMap a common case is to get large contiguous chunks of keys,
so logical big-endian trieing improves performance over logical
little-endian. I'm not sure how common large contiguous chunks of
bytestring keys are, though. Reading a word then changing the physical
endianness of the bytes seems expensive.
--
Live well,
~wren
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
