Re: Restore Header Table and Static Table Indices

[Adrian Cole <[e-mail]>]

+1

For apis, this makes a lot of sense, as often custom headers equal or
outnumber ones in the static table.
This part of the implementation is easy, so churn isn't an issue for
me personally.

On Mon, Oct 6, 2014 at 2:58 PM, Roberto Peon <[e-mail]> wrote:
> I'm a +1 on this.
>
> The data thusfar shows that the current scheme significantly underperforms
> the previously designed scheme when the headers to be used are not in the
> current static set.
>
> The complexity of adding an int to an int is low.
> The amount of CPU necessary to add an int to an int is low.
>
> The difference in performance in the non-idea case is large.
>
> -=R
>
> On Mon, Oct 6, 2014 at 2:17 PM, Simpson, Robby (GE Energy Management)
> <[e-mail]> wrote:
>>
>> I too am a -1
>>
>> On 10/6/14, 4:44 PM, "Michael Sweet" <[e-mail]> wrote:
>>
>>
>> >Also -1.
>> >
>> >> On Oct 6, 2014, at 2:44 PM, Poul-Henning Kamp <[e-mail]>
>> >>wrote:
>> >>
>> >> --------
>> >> In message <[e-mail]>, "Kulkarni, Saurabh"
>> >>writes:
>> >>> Same here, -1 on this. Our implementation (Akamai server) is much
>> >>>simpler
>> >>> now because of this.
>> >>
>> >> Same here: -1 on this.
>> >>
>> >> Having the static table first is much simpler and no credible data
>> >> has shown that putting the dynamic table first will lead to overall
>> >> improvement of compression.
>> >>
>> >> And if compression is that important, we can get much more of it by
>> >> compressing timestamps algorithmically than by flipping these two
>> >> tables.
>> >>
>> >> --
>> >> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>> >> [e-mail]         | TCP/IP since RFC 956
>> >> FreeBSD committer       | BSD since 4.3-tahoe
>> >> Never attribute to malice what can adequately be explained by
>> >>incompetence.
>> >>
>> >
>> >_________________________________________________________
>> >Michael Sweet, Senior Printing System Engineer, PWG Chair
>> >
>> >
>>
>>
>