Home/ Questions/Q 7507695
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T22:32:27+00:00

Java is Big-Endian; Network stack is Big-Endian; Intel/AMD (basically all of our computers) and

  • 0

Java is Big-Endian; Network stack is Big-Endian; Intel/AMD (basically all of our computers) and ARM CPU’s (most common Android and iOS chips) are all little-endian as well.

Given all of that, if I am allocating a direct ByteBuffer for different uses, is it a good idea to always try and match the endian-ness of the native interaction?

More specifically:

  • Network Buffer: Leave it Big-Endian.
  • File Buffer (on x86): Little-Endian.
  • OpenGL/Native Process Buffer: Little-Endian.

and so on…

I am asking this because I have never thought about the Endian-ness of my ByteBuffers, but after seeing some other questions on SO and the performance impact it can have, it seems worth it or at least something I should become more aware of when utilizing ByteBuffers.

Or maybe there is a down-side here to worrying about endian-ness I am missing and would like to be aware of?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It points out in the article you quote that the difference is pretty small. (Possibly none)

    The results quoted don’t show a consistent improvement and using the latest JVMs may close the gap.

    • When I enable “native byte ordering” (which is actually unsafe if the machine uses a different ‘endian’ convention):
    mmap: 1.358
bytebuffer: 0.922
regular i/o: 1.387
    • When I comment out the order statement and use the default big-endian ordering:
    mmap: 1.336
bytebuffer: 1.62
regular i/o: 1.467

    There is a measured difference but its small in the overall scheme of things. If you want it to be much faster, the only option I have found which makes a big difference is using Unsafe directly, in which case only native ordering is available.

    Even then it only helps in the most latency sensitive applications.

    Unsafe is even more interesting with code and comments. 😉

    http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/misc/Unsafe.java

    • 0