Brute force can work.


This initial value I have is rather difficult when it comes to elimination.


Actually, I could use what I have now as a kind of heuristic and have a spliced off huffman tree which is in four parts. That would reduce the runtime memory requirement so to speak. I would need to be in all active trees at the same time however. If a rover falls off the tree then it is not that route. If I were to visuallize the entire huffman tree and its routes.


I would not need a tree if I made a gigantic method which does comparisons on all of the tree values. So basically it would just consist of branches. Then it could exist in the ROM. I do wonder how big such a method would be though since there are byte code limitations.


Well the gigantic method of ifs seems faster. The gigantic method of ifs is about 3887 byte codes long. I could actually do better with it. Right now the byte code is just getting the field every single time even though it is final, I can just pass it to the method instead.


And having it invoke a method is 3038 bytes of byte code.


I can also compact the giant method a bit by removing some of the leaves since now I notice a pattern to the bits.


The byte code count really goes down when I compact a large portion of the tree into a single addition.


For now.

2824  2016-03-11 09:46   net/multiphasicapps/io/DeflateFixedHuffman.class

Then removing some very large branches

1360  2016-03-11 09:50   net/multiphasicapps/io/DeflateFixedHuffman.class


Then a final compaction brings me to:

932  2016-03-11 09:53   net/multiphasicapps/io/DeflateFixedHuffman.class

So initially it was 3887 reading a field, then 3038 when not reading it. Now with the maximum compaction of the tree it is 156 byte codes long. So this is rather very nice. So what I have now is about 5% original size. So now after having a built-in fixed tree, there is no more need for a global and such. The only thing I require generation for is the dynamic huffman tree.


It also just takes up 28 lines of code, which is quite simple. This is compared to the previous 500 or so lines.


I am going to need a generic inflation or deflation routine which is then put through a processor. So instead of InflaterInputStream there is some kind of chunked stream instead which is initialized with a processor. The input/output stream variants of it would in general just process the bytes. This would be handy because in the future I am going to need a cleaner way to handle GZip and ZLib streams which use Deflate without creating a bunch of wrapped input streams and such.


I believe having a given byte buffer backing for the CircularBitBuffer would complicate the implementation.


I could just use a boolean array, a smart JVM will just use a compact form of it anyway so I really do not need to worry about space efficiency because it is hidden away.


And forcing a minimum number of bits would be easier implementing a decompressor because then I would need to handle partial bit states and such. It would just be easier because I can read a bunch of bits without worrying about running out (during say a fixed huffman read).


I can also use a base class for the buffers since right now they have a bunch of duplicate code.


I cannot use single arrays with the generics though since the types clash with the primitive type and I cannot specify an array of a primitive type.


NoSuchFieldError and IncompatibleClassChangeError are also required by the compiler to operate properly.