00:03
Brute force can work.
00:13
This initial value I have is rather difficult when it comes to elimination.
00:16
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.
08:48
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.
09:08
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.
09:14
And having it invoke a method is 3038 bytes of byte code.
09:24
I can also compact the giant method a bit by removing some of the leaves since now I notice a pattern to the bits.
09:47
The byte code count really goes down when I compact a large portion of the tree into a single addition.
09:50
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
09:53
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.
09:59
It also just takes up 28 lines of code, which is quite simple. This is compared to the previous 500 or so lines.
11:46
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.
17:31
I believe having a given byte buffer backing for the CircularBitBuffer
would complicate the implementation.
17:43
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.
17:49
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).
17:57
I can also use a base class for the buffers since right now they have a bunch of duplicate code.
19:38
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.
20:42
NoSuchFieldError and IncompatibleClassChangeError are also required by the
compiler to operate properly.