-2

Searching yields many questions about how to convert an int to byte[]. I have a project with a critical loop that writes a long int[] to a FileOutputStream. FileOutputStream requires a byte[] for writing. I can brute-force different methods; I'm looking for a way to send an int[] directly to a FileOutputStream or the fastest method to convert int[] to byte[] - something like wrapping a buffer. I see ways to wrap a byte[] to convert to int[] and float[]... but none the other way (from int[] to byte[]). Thanks.

Update: still hoping to avoid the complexity (or experimenting - for now) of memory mapped I/O until the need is proven. The comments below prompted me to look at creating a ByteBuffer, wrapping it in an IntBuffer, writing ints to the IntBuffer, then extracting a byte[] from the ByteBuffer to send to the FileOutputStream. The obvious alternative is just to use byte[] directly, which requires that I manipulate my data as bytes rather than ints, which I can do - but how much more efficient (if at all) is it compared to the byte[]/ByteBuffer/IntBuffer wrapping scheme?

Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140
ags
  • 719
  • 7
  • 23
  • For clarification, these are byte values (0-255) that are being stored as ints. You don't have an array of `{0, 100, 1000, 100000}` and want to print those. If so, http://stackoverflow.com/questions/1086054/java-how-to-convert-int-to-byte – Paul Draper Oct 27 '13 at 06:40
  • Other link http://stackoverflow.com/questions/4358875/fastest-way-to-write-an-array-of-integers-to-a-file-in-java?rq=1 – makasprzak Oct 27 '13 at 06:46
  • More specifically, I have int[14] and I want to write that in little-endian order to a file, with good efficiency. The link provided takes a different approach (which I could use if that's the best way - but requires more modification) which starts with a ByteBuffer, (apparently) wraps it with an IntBuffer, adds data (one int at a time) to the IntBuffer, then extracts a byte[] - which for my use would then be written to the FileOutputStream. Is that an efficient method? – ags Oct 27 '13 at 06:49

2 Answers2

2

Your bottleneck is most likely to be your disk IO so what you do in CPU doesn't matter. I would make sure you trying to solve a problem which will make a difference to your application.

If you have a fast disk sub system and you have short bursts of data, your CPU can matter and the fastest way to do the conversion is to avoid performing the conversion in the first place, ie don't use a byte[] at all. An example if OpenHFT/Java Chronicle this takes an int value and writes it direct to a memory mapped file memory region as a 32-bit value. This means each write consists of a single machine code instruction and takes about 1.5 ns on average.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • Yes, good point about disk I/O and I did consider that. I may be writing files of 100+MB and am unfamiliar with all but the basics of memory mapped I/O. I am happy to start (until measurements show further optimization is needed) with letting java deal with buffered I/O. At first pass I'm looking to avoid unnecessary copying of data from int[] to byte[] just to get it out to a FileOutputStream (or something else that might be more suitable). – ags Oct 27 '13 at 07:00
  • 1
    @ags I would concentrate on the slowest parts of your system first. You can do a direct copy from `int[]` to `byte[]` using sun.misc.Unsafe but if the array is large enough, it is your L3 cache to memory bandwidth which will be the limiting factor and how you do it won't matter. Creating the byte[] in the first place could cost more. NOTE: your byte[] has to be copied to native memory which is why Java-Chronicle copies directly into native memory to avoid all of that. – Peter Lawrey Oct 27 '13 at 07:06
0

Try ObjectOutputStream.writeObject(intArray). You can later read it with ObjectIntputStream.readObject

Evgeniy Dorofeev
  • 133,369
  • 30
  • 199
  • 275
  • While simpler, this would be much slower as it turns the int[] into a byte[] and much more. – Peter Lawrey Oct 27 '13 at 07:08
  • Agreed. While useful for Serialization of heterogeneous types for persistent storage and later Deserialization, I've measured significant performance impact using this when not necessary. – ags Oct 27 '13 at 07:39