2016/03/11

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.