Cormac Blackwell

Ok what the heck is the point of actual? What is the stream coming in as? Strings or byte arrays? Calling getBytes on a String is very slow and of course is creating new bytes arrays which will cause garbage collection.

Actually if equals against a string or toString is getting called you are allocating lots of objects for no apparent reason.

I would say you could be better of using Strings instead of Symbols and possibly interning the Strings

Object creation is almost free if the object is not held on too.

If the symbol is coming in as a byte array and it won't change while you are doing the lookup then you could use a much simpler wrapper

If you can't figure out your Java performance problems and go to C++ you are going to be well and truly boned.

Well you are creating a new char array in a loop and everytime you find a character you want to replace you are copying the whole string!
Try creating a single char array at the beginning which is twice the size you think you will need, then for each char either copy it or the replacement in (and resize the output array only if necessary and double the size if you have to resize it at all). Then you can contruct a string from the section of the array you have used. Also you probably should store the replacement strings as char arrays if you are just going to call toCharArray on them.

Actually I have a vague memory that toCharArray isn't that fast so you could be better off switching on string.charAt and appending to a single StringBuilder.

It was pretty simple

start = System.currentTimeMillis(); for(int i = 0; i < 100000000; i++) { bitsInInt(1); bitsInInt(2); bitsInInt(3); bitsInInt(5); bitsInInt(Integer.MAX_VALUE); } end = System.currentTimeMillis();

I had this inside an infinite loop so I could see any effects of jit compilation. Maybe the server VM is figuring out the results are always the same.

Resusing objects can be one of the worst things you can do for garbage collection times. Have a look at http://javaspecialists.co.za/archive/Issue115.html
You also could have a look at high performance collection libraries like trove or javolution.

A little while ago Larry Osterman (http://blogs.msdn.com/larryosterman/) wrote a post about optimisation tricks for counting the number of set bits in an int. I decided to try a few just out of curiosity of what java would do. the first one was the naive implementation:

public static int countSetBits(int x) { int set = 0; for(int i = 0; i < 32 && x != 0; i++) { set += x & 1; x >>= 1; } return set; }
This takes about 11 secs for 500,000,000 runs.

The most interesting result was with a lookup table based solution
public static int bitsInNybble(int n) { // 8-entry lookup table switch (n) { // four bits case 0xf: return 4; // three bits case 0xe: case 0xd: case 0xb: case 0x7: return 3; // two bits case 0xc: case 0xa: case 0x9: case 0x6: case 0x5: case 0x3: return 2; // one bit case 0x8: case 0x4: case 0x2: case 0x1: return 1; // zero bits case 0: return 0; } return 0; } public static int bitsInInt(int x) { return bitsInNybble(x & 0xf) + bitsInNybble(x >> 4 & 0xf) + bitsInNybble(x >> 8 & 0xf) + bitsInNybble(x >> 12 & 0xf) + bitsInNybble(x >> 16 & 0xf) + bitsInNybble(x >> 20 & 0xf) + bitsInNybble(x >> 24 & 0xf) + bitsInNybble(x >> 28 & 0xf); }

This seemed to be horribly slow; around 34 secs for the same number of iterations.
But then I tried using the server VM. With that one the first 500,000,000 took around 12ms and from then on 0ms for the same number!!
So the client VM in this case is over 24,000 times slower!!!

Anyone have any idea what is going on?