Re: HPACK benchmark test for substitution indexing vs incremental indexing only

We still need to change the place the incremental indexing gets indexed--
it needs to be indexed at 0. This made a noticable change in the output
(>1%) on an older compressor.
-=R


On Mon, Oct 7, 2013 at 9:46 AM, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>wrote:

> > -----Original Message-----
> > From: Tatsuhiro Tsujikawa [mailto:tatsuhiro.t@gmail.com]
> > Sent: samedi 28 septembre 2013 16:36
> > To: RUELLAN Herve
> > Cc: Mike Bishop; Gábor Molnár; Roberto Peon; ietf-http-wg@w3.org
> > Subject: Re: HPACK benchmark test for substitution indexing vs
> incremental
> > indexing only
> >
> >
> >
> >
> > On Sat, Sep 28, 2013 at 1:34 AM, RUELLAN Herve
> > <Herve.Ruellan@crf.canon.fr> wrote:
> >
> >
> >       I've ran some tests on the "mnot" test set and I've been able to
> see
> > some effect from using substitution:
> >       - Substituting compressor:   29.5%
> >       - Append-only compressor: 30.3%
> >
> >
> >
> >
> > Since these numbers are much better than the my results (which is 39% and
> > 37% respectively), I'm very interested in the algorithm you used to
> achieve
> > them.
> >
> > Could you share it with us?
> > Is it some kind of algorithm to take advantage of the complete knowledge
> of
> > incoming headers?
> > Or based on statistics on today's web traffic?
>
> I'll try to publish my algorithms. They do nothing fancy and are rather
> simple.
>
> > Note that my results combine request and response headers.
>
> My results also combine the figures for request and response headers. They
> were generated using the http2 compression testing framework (
> https://github.com/http2/compression-test).
> The differences may come from the condition of the test, in particular in
> the way the testing framework group messages into different "HTTP/2.0
> sessions".
>
> > Because of relative difference is small, I'm lean to the side to remove
> > substitution for now.
> > Mostly it is because the decoder have to pay for it. The encoder can
> just skip
> > substitution if it wants, but decoder has no choice.
>
> By tweaking my substituting compressor, I'm able to get more compaction.
> On long-running connections, the difference between the two compressors is
> greater, and on some test cases, the substituting compressor can be 3 or 4
> points lower than the Append-only compressor.
>
> I think that the substituting compressor offers some potential room for
> future compaction improvement.
>
> Best regards,
>
> Hervé.
>
>