DISCLAIMER: These notes are from the defunct k8 project which precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26! The k8 project was effectively a Java SE 8 operating system and as such all of the notes are in the context of that scope. That project is no longer my goal as SquirrelJME is the spiritual successor to it.


Appears locking is not an issue because it makes no difference in how long the code takes to execute.


So far at least when it comes to exceptions, it appears that my code is only slightly faster than before.


Comparison of before and afters...


    Before          After
    (KBF)   (24)    (KBF)   (24)
    495     58      457     70
    409     52      411     78
    414     51      413     69
    413     51      413     62
    649     89      408     67
    497     78      405     65
    397     53      651     110
    416     56      406     68
    411     54      413     64
    400     49      507     64
min 397     49      405     62
avg 450.1   59.1    448.4   71.7
max 649     89      651     110

So on average my code in total is about the same speed but slightly faster, however the constant pool reading is a definite 20ms slower. So while other sections sped up, the constant pool slowed down. The class I am testing is very minimal however so it is possible that it may speed up in general for all classes compared to before. So the class I am testing is a rather bad test class for the most part. Suppose the class I should test instead is the PowerPC operand table which (or the Java byte code table) has a few thousand enum elements and such. Well I cannot test that because my KBF code is incomplete so I will have to go back to it. In the future I need to set the project main class to net.multiphasicapps.k8.binary.asm.ppc.PowerPCInstruction:main and the previous "before" revision I used was 9b791606e18e8c2a94c28467feac4df2c2df709b. Seeing that the constant pool code is a bit slow I can determine how it is best to speed it up so it is as fast as it was before. The giant enumeration is constant heavy 8,241 entries. What I can do before hand is determine the speed of the before right now and then just come back to it.


    Before          After
    (KBF)   (8241)  (KBF)   (?)
    3072    741     
    2911    739     
    3961    846     
    2868    682     
    2866    705     
    2933    691     
    3001    696     
    2878    725     
    3667    1080        
    2933    696     
min 2866    682 0   0
avg 3109    760.1   #DIV/0! #DIV/0!
max 3961    1080    0       0

Since the Mutable KBF code is incomplete I no after code to compare with. If it is slower then I may possibly know how to optimize the code.


Seems my newly rewritten code is slower, but I have a few optimization tricks up my sleeves.


Suppose I wasted these few days rewriting code just to make it slower although it appears much more efficient. The constant stuff might be what is causing the major slowdown however. Had to make the local variable table use JavaType because that includes ReferenceType and primitives.


Well, my old code used ByteBuffers for containing class data and contained lots of assumptions as to what is stored in structures. I suppose those assumptions made it a bit speedy. However I like the new more type-safe-ness and the possibility of multiple TOCs. In order to go back to buffer I only need to change a single class. One thing though is that arrays are seen as objects themselves. Right now structures are always created for every element, wheras before they were sort of on-demand. Oh well, so the rewrite was a partial failure.


Using buffers will simplify allocations. Perhaps there is also a way where I can cheat when it comes to constants. The constants can use a set and then just iterate though all of the entries and structures grabbing them all. But that is only needed during iteration. I suppose constant lookup can then be lazy where it is only generated when it is asked for.