Thread history

I've had some success using Proguard to shrink a few bytes off of microbots when they really need it - eg. Yatagan requires this. It usually does it by re-assigning variables into a slot that is no longer used - note that the actual java asm is not type-aware, so you can stick one type of object into the variable you previously used for a different type of variable. This means you can better re-use the initial few variables, which have lower codesize cost.

IMO you'll get better effective shrinking by exploring the library - for example, the pattern matcher nanos are all using string and substring indexOf functions, they would never have space to put all of the actual matching code in.

I think making use of library may be much useful than micro-optimizing bytecode size. Bytecode tools can be used for a few additional bytes though.

As well as exploring the standard library it's also a good idea to carefully consider the robocode methods as well. For example, I was able to save a few bytes by switching from setTurnRightRadians to setTurnLeftRadians as it allowed me to save the result of getHeadingRadians in a register instead of calling it twice.

I didn't have any success with ProGuard when trying to shrink Quantum but switching to assembly with Krakatau has been quite fruitful. I've been able to save space by using dup to save variables on the stack instead of using local variables, which wouldn't have been possible in plain Java.

After my next update to Quantum I'll write a walkthrough from naive Java to optimised Java and finally down to bytecode. I'll be able to demonstrate most of the techniques listed in this page as well as a few new ideas like my gunheat lock for the radar.

Something I haven't explored yet is whether nested calls to event handlers can be exploited in some way. I don't think I could make use of it in Quantum but if/when I write a nano duelist it might come in handy.