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