- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Thu, 07 Aug 2014 04:36:07 +1200
- To: ietf-http-wg@w3.org
On 7/08/2014 3:07 a.m., Jeff Pinner wrote: >> There is also another good benefit for encoding with static indexes low. >> Because the index does not change for fields like Date and Server, you can >> every second pre-encode the bytes for fields like: >> >> server: jetty-9.3.0 >> date: Wed, 06 Aug 2014 05:19:19 GMT >> >> With the static index's low, this pre-encoded value is the same for all >> connection, as it is not a function of the size of the dynamic table of each >> connection. Thus the same pre-encoded value may be used 10s of thousands >> of times, rather than encoding these fields on each and every response for >> each and every connection. >> >> cheers > > you still pre-encode the huffman strings > > are you talking about pre-encoding the index for "date" to 33 instead > of 33 + headerTable.length() ? > > if so, i'd argue that the pre-encoded huffman buys you way more than > the bit of arithmetic before you copy into the send buffer and doing > the addition is well worth the tradeoff > Every table entry could have a huffman pre-encoded for its index number and just dump that out. The same optimization can be applied to both header orderings and the remaining problem in that particuular calculation is the repeated acts of addition when static follows dynamic. Also, don't forget the effected context. When inserting/deleting into dynamic table all the static entries have to be re-indexed on top of any later dynamic entries. All unnecessary work when static comes first. Amos
Received on Wednesday, 6 August 2014 16:36:42 UTC