I made two "significant" optimizations. The first is to add a CompareNull and CompareNotNull opcode to use in fcode. The compiler will use now use this opcode if it sees various combinations of ==, !=, ===, or !== with a null.
The second optimization is in the Java emitter to peek at the next opcode when emitting a comparison. If the next opcode is a JumpFalse or JumpTrue, then the emitter can optimize to use a special Java branch instruction. For instance a combination of CompareNull and JumpTrue can be emitted as a single "ifnull" Java opcode. A combination of CompareLT with JumpX can use an alternate method in OpUtil which returns a boolean versus a Bool to skip the need to do a getfield on Bool.val. I think using a peek approach versus a bunch of new opcodes for the combinations is a more elegant solution.
Further optimizations with comparisons will require me to know if either side can be null - right now something like x < 3 is fairly expensive because I don't know that x can't be null - so I have to route to OpUtil.compareLT which checks both sides for null before calling Obj.equals(). So a single opcode in pure Java results at least two method and a dozen opcodes.
Unfortunetely the optimizations I did implement hardly put a dent in the performance of the Tokenizer. I shaved off a few milliseconds dropping the time to tokenize sysTest from 708ms to 690ms. I think I'm going to move onto the Parser and see what kind of performance I get there since it is largely data structure manipulation versus IO manipulation
brian Fri 2 Jun 2006
I made two "significant" optimizations. The first is to add a CompareNull and CompareNotNull opcode to use in fcode. The compiler will use now use this opcode if it sees various combinations of ==, !=, ===, or !== with a null.
The second optimization is in the Java emitter to peek at the next opcode when emitting a comparison. If the next opcode is a JumpFalse or JumpTrue, then the emitter can optimize to use a special Java branch instruction. For instance a combination of CompareNull and JumpTrue can be emitted as a single "ifnull" Java opcode. A combination of CompareLT with JumpX can use an alternate method in OpUtil which returns a boolean versus a Bool to skip the need to do a getfield on Bool.val. I think using a peek approach versus a bunch of new opcodes for the combinations is a more elegant solution.
Further optimizations with comparisons will require me to know if either side can be null - right now something like x < 3 is fairly expensive because I don't know that x can't be null - so I have to route to OpUtil.compareLT which checks both sides for null before calling Obj.equals(). So a single opcode in pure Java results at least two method and a dozen opcodes.
Unfortunetely the optimizations I did implement hardly put a dent in the performance of the Tokenizer. I shaved off a few milliseconds dropping the time to tokenize sysTest from 708ms to 690ms. I think I'm going to move onto the Parser and see what kind of performance I get there since it is largely data structure manipulation versus IO manipulation