Question

I am working on a Java application where I need to send an array of 500,000 integers from one Android phone to another Android phone over a socket connection as quickly as possible. The main bottleneck seems to be converting the integers so the socket can take them, whether I use ObjectOutputStreams, ByteBuffers, or a low level mask-and-shift conversion. What is the fastest way to send an int[] over a socket from one Java app to another?

Here is the code for everything I’ve tried so far, with benchmarks on the LG Optimus V I’m testing on (600 MHz ARM processor, Android 2.2).

Low level mask-and-shift: 0.2 seconds

public static byte[] intToByte(int[] input)
{
    byte[] output = new byte[input.length*4];

    for(int i = 0; i < input.length; i++) {
        output[i*4] = (byte)(input[i] & 0xFF);
        output[i*4 + 1] = (byte)((input[i] & 0xFF00) >>> 8);
        output[i*4 + 2] = (byte)((input[i] & 0xFF0000) >>> 16);
        output[i*4 + 3] = (byte)((input[i] & 0xFF000000) >>> 24);
    }

    return output;
}

Using ByteBuffer and IntBuffer: 0.75 seconds

public static byte[] intToByte(int[] input)
{
    ByteBuffer byteBuffer = ByteBuffer.allocate(input.length * 4);        
    IntBuffer intBuffer = byteBuffer.asIntBuffer();
    intBuffer.put(input);

    byte[] array = byteBuffer.array();

    return array;
}

ObjectOutputStream: 3.1 seconds (I tried variations of this using DataOutPutStream and writeInt() instead of writeObject(), but it didn’t make much of a difference)

public static void sendSerialDataTCP(String address, int[] array) throws IOException
{
    Socket senderSocket = new Socket(address, 4446);

    OutputStream os = senderSocket.getOutputStream();
    BufferedOutputStream  bos = new BufferedOutputStream (os);
    ObjectOutputStream oos = new ObjectOutputStream(bos);
    oos.writeObject(array);

    oos.flush();
    bos.flush();
    os.flush();
    oos.close();
    os.close();
    bos.close();

    senderSocket.close();
}

Lastly, the code I used to send byte[]: takes an addition 0.2 seconds over the intToByte() functions

public static void sendDataTCP(String address, byte[] data) throws IOException
{
    Socket senderSocket = new Socket(address, 4446);

    OutputStream os = senderSocket.getOutputStream();
    os.write(data, 0, data.length);
    os.flush();

    senderSocket.close();
}

I’m writing the code on both sides of the socket so I can try any kind of endianness, compression, serialization, etc. There’s got to be a way to do this conversion more efficiently in Java. Please help!

Answer 1

As I noted in a comment, I think you’re banging against the limits of your processor. As this might be helpful to others, I’ll break it down. Here’s your loop to convert integers to bytes:

    for(int i = 0; i < input.length; i++) {
        output[i*4] = (byte)(input[i] & 0xFF);
        output[i*4 + 1] = (byte)((input[i] & 0xFF00) >>> 8);
        output[i*4 + 2] = (byte)((input[i] & 0xFF0000) >>> 16);
        output[i*4 + 3] = (byte)((input[i] & 0xFF000000) >>> 24);
    }

This loop executes 500,000 times. You 600Mhz processor can process roughly 600,000,000 operations per second. So each iteration of the loop will consume roughly 1/1200 of a second for every operation.

Again, using very rough numbers (I don’t know the ARM instruction set, so there may be more or less per action), here’s an operation count:

• Test/branch: 5 (retrieve counter, retrieve array length, compare, branch, increment counter)
• Mask and shift: 10 x 4 (retrieve counter, retrieve input array base, add, retrieve mask, and, shift, multiply counter, add offset, add to output base, store)

OK, so in rough numbers, this loop takes at best 55/1200 of a second, or 0.04 seconds. However, you’re not dealing with best case scenario. For one thing, with an array this large you’re not going to benefit from a processor cache, so you’ll introduce wait states into every array store and load.

Plus, the basic operations that I described may or may not translate directly into machine code. If not (and I suspect not), the loop will cost more than I’ve described.

Finally, if you’re really unlucky, the JVM hasn’t JIT-ed your code, so for some portion (or all) of the loop it’s interpreting bytecode rather than executing native instructions. I don’t know enough about Dalvik to comment on that.