Re: Updated Delta+BOHE Impl in Java

FYI... compression-test suite integration is done... still have lots
of testing and fine tuning of the overall implementation to do, but
it's now possible to run this through the compression-test toolset.

Just pull the code from github and run the maven build, then from the
compression-test directory, do...

./compare_compressors.py -c
fork="{path_to_code}/http2/compression_test.sh" -c delta2 \
   ../http_samples/mnot/craigslist.org.har

where {path_to_code} is the full path to the java code...

* TOTAL: 33 req messages

   size  time | ratio min   max   std
                                                           http1
 13,389  0.00 | 1.00  1.00  1.00  0.00
  fork (/Users/james/Workspaces/specs/http2/compression_test.sh)
  2,489  0.01 | 0.19  0.07  0.75  0.11
                                                          delta2
  1,812  0.04 | 0.14  0.05  0.61  0.10

* TOTAL: 33 res messages

   size  time | ratio min   max   std
                                                           http1
 10,363  0.00 | 1.00  1.00  1.00  0.00
  fork (/Users/james/Workspaces/specs/http2/compression_test.sh)
  1,656  0.00 | 0.16  0.07  0.54  0.11
                                                          delta2
  2,452  0.02 | 0.24  0.06  0.55  0.10

On Tue, Apr 9, 2013 at 10:24 AM, James M Snell <jasnell@gmail.com> wrote:
> I have updated my experimental Delta+Bohe java implementation to match
> the current draft of the specification and Roberto's current delta
> iteration. I still have to patch this in to the compression-test stuff
> but the code is functional.
>
>   https://github.com/jasnell/http2
>
> Requires maven to build. Dependencies are light. Still needs a ton of
> work and I have not even started working on performance optimizations.
> It's a pretty straight forward port of everything Roberto has done in
> the python impl.
>
> The one bit this does add is multi-type header values. The types
> supported are String, Number, Datetime and Binary. Strings can be
> either UTF-8 or ISO-8859-1. If they are ISO-8859-1, they can be
> Huffman coded using Roberto's static code. I am using an different
> static dictionary of predefined header values tho.
>
> General takeaways ..
>
> 1. The implementation is not that difficult to do and seems to perform
> reasonably well.
> 2. The additional types are very useful and add minimal additional
> complexity to the implementation.
> 3. I'm generally not convinced that we really need the huffman coding.
> Yes, it saves a handful of bytes here and there but it does add
> additional complexity. I can live with it tho. If we keep it and we
> decide to allow for UTF8 header values, then we need to come up with a
> static huffman coding that includes the extended UTF8 character
> support.
> 4. Performance seems reasonable overall.
>
> I'm going to be working on implementing HeaderDiff next. Hopefully
> I'll have the time to have that done by this Friday.
>
> - James

Received on Thursday, 11 April 2013 18:06:28 UTC