assets/developer-notes/stephanie-gawroriski/2016/03/11.mkd

   1 # 2016/03/11
   2
   3 ## 00:03
   4
   5 Brute force can work.
   6
   7 ## 00:13
   8
   9 This initial value I have is rather difficult when it comes to elimination.
  10
  11 ## 00:16
  12
  13 Actually, I could use what I have now as a kind of heuristic and have a spliced
  14 off huffman tree which is in four parts. That would reduce the runtime memory
  15 requirement so to speak. I would need to be in all active trees at the same
  16 time however. If a rover falls off the tree then it is not that route. If I
  17 were to visuallize the entire huffman tree and its routes.
  18
  19 ## 08:48
  20
  21 I would not need a tree if I made a gigantic method which does comparisons on
  22 all of the tree values. So basically it would just consist of branches. Then
  23 it could exist in the ROM. I do wonder how big such a method would be though
  24 since there are byte code limitations.
  25
  26 ## 09:08
  27
  28 Well the gigantic method of ifs seems faster. The gigantic method of ifs is
  29 about 3887 byte codes long. I could actually do better with it. Right now the
  30 byte code is just getting the field every single time even though it is final,
  31 I can just pass it to the method instead.
  32
  33 ## 09:14
  34
  35 And having it invoke a method is 3038 bytes of byte code.
  36
  37 ## 09:24
  38
  39 I can also compact the giant method a bit by removing some of the leaves since
  40 now I notice a pattern to the bits.
  41
  42 ## 09:47
  43
  44 The byte code count really goes down when I compact a large portion of the
  45 tree into a single addition.
  46
  47 ## 09:50
  48
  49 For now.
  50
  51         2824  2016-03-11 09:46   net/multiphasicapps/io/DeflateFixedHuffman.class
  52
  53 Then removing some very large branches
  54
  55         1360  2016-03-11 09:50   net/multiphasicapps/io/DeflateFixedHuffman.class
  56
  57 ## 09:53
  58
  59 Then a final compaction brings me to:
  60
  61         932  2016-03-11 09:53   net/multiphasicapps/io/DeflateFixedHuffman.class
  62
  63 So initially it was 3887 reading a field, then 3038 when not reading it. Now
  64 with the maximum compaction of the tree it is 156 byte codes long. So this is
  65 rather very nice. So what I have now is about 5% original size. So now after
  66 having a built-in fixed tree, there is no more need for a global and such. The
  67 only thing I require generation for is the dynamic huffman tree.
  68
  69 ## 09:59
  70
  71 It also just takes up 28 lines of code, which is quite simple. This is compared
  72 to the previous 500 or so lines.
  73
  74 ## 11:46
  75
  76 I am going to need a generic inflation or deflation routine which is then put
  77 through a processor. So instead of `InflaterInputStream` there is some kind of
  78 chunked stream instead which is initialized with a processor. The input/output
  79 stream variants of it would in general just process the bytes. This would be
  80 handy because in the future I am going to need a cleaner way to handle GZip
  81 and ZLib streams which use Deflate without creating a bunch of wrapped input
  82 streams and such.
  83
  84 ## 17:31
  85
  86 I believe having a given byte buffer backing for the `CircularBitBuffer`
  87 would complicate the implementation.
  88
  89 ## 17:43
  90
  91 I could just use a boolean array, a smart JVM will just use a compact form of
  92 it anyway so I really do not need to worry about space efficiency because it
  93 is hidden away.
  94
  95 ## 17:49
  96
  97 And forcing a minimum number of bits would be easier implementing a
  98 decompressor because then I would need to handle partial bit states and such.
  99 It would just be easier because I can read a bunch of bits without worrying
 100 about running out (during say a fixed huffman read).
 101
 102 ## 17:57
 103
 104 I can also use a base class for the buffers since right now they have a bunch
 105 of duplicate code.
 106
 107 ## 19:38
 108
 109 I cannot use single arrays with the generics though since the types clash
 110 with the primitive type and I cannot specify an array of a primitive type.
 111
 112 ## 20:42
 113
 114 `NoSuchFieldError` and `IncompatibleClassChangeError` are also required by the
 115 compiler to operate properly.
 116
 117