4 ms·

Any evidence this actually causes material performance improvement? Pre-shared compression dictionaries are rarely seen in the wild because they rarely provide

Any evidence this actually causes material performance improvement? Pre-shared compression dictionaries are rarely seen in the wild because they rarely provide meaningful benefit, particularly in the cases you care about most.

CaptainOfCoit 2y ago
I guess you should outline the cases you care the most about, for anyone to be able to answer if there is any material performance improvements.
- hansvm 2y ago
  The only requirements are serving a lot of the same "kind" of content, enough such (or for some other business reason) that it doesn't make sense to send it all at once, and somebody willing to spend a bit of time to implement it. Map and local geocoding information comes to mind as a decent application, and if the proposed implementation weren't so hyper-focused on common compression standards you could probably do something fancy for, e.g., meme sites (with a finite number of common or similar background images). Assuming (perhaps pessimistically) it won't work well for most sites serving images, other possibilities include: - Real-estate searches (where people commonly tweak tons of parameters and geographies, returning frequently duplicated information like "This historical unit has an amazing view in each of its 2 bedrooms"). - Expanding that a bit, any product search where you expect a person to, over time, frequently query for the same sorts of stuff. - Local business information (how common is it to open at 10am and close at 6pm every weekday in some specific locale for example). ... If the JS, image, and structural HTML payloads dwarf everything else then maybe it won't matter in practice. I bet somebody could make good use of it though.
therein 2y ago
Yup, we did experiment with SDCH at a large social network around 2015 and it didn't massively outperform gzip. Outperforming it required creating a pipeline for dynamic dictionary generation and distribution.
- itsthecourier 2y ago
  SDHC?
  - morsch 2y ago
    Shared Dictionary Compression for HTTP https://en.m.wikipedia.org/wiki/SDCH https://en.m.wikipedia.org/wiki/SDCH
csswizardry 2y ago
Huge, huge improvements. I’ve been following this spec keenly. 1. https://compression-dictionary-transport-threejs-demo.glitch.me/ https://compression-dictionary-transport-threejs-demo.glitch... 2. https://compression-dictionary-transport-shop-demo.glitch.me/ https://compression-dictionary-transport-shop-demo.glitch.me...
fnordpiglet 2y ago
If you care about latencies or are on very low bandwidth or noisy connections preshared dictionaries matter a lot. By and large they generally always help but come with complexity so are often avoided in favor of a simpler approach whose compression is acceptable rather than optimal. But if there’s a clear and well implemented standard that’s widely adopted I would always choose preshared dictionaries. Likewise secure connections are hard and without TLS and other standards most people wouldn’t try unless they really needed it. But with a good standard and broad implementation it’s basically ubiquitous.
itsthecourier 2y ago
Bro, this stuff will be wild for our iot stuff
vitus 2y ago
The one example I can think of with a pre-seeded dictionary (for web, no less) is Brotli. https://datatracker.ietf.org/doc/html/rfc7932#appendix-A https://datatracker.ietf.org/doc/html/rfc7932#appendix-A You can more or less see what it looks like (per an older commit): https://github.com/google/brotli/blob/5692e422da6af1e991f9182345d58df87866bc5e/java/org/brotli/dec/DictionaryData.java https://github.com/google/brotli/blob/5692e422da6af1e991f918... Certainly it performs better than gzip by itself. Some historical discussion: https://news.ycombinator.com/item?id=19678985 https://news.ycombinator.com/item?id=19678985
- duskwuff 2y ago
  A more readable version of the Brotli dictionary: https://gist.github.com/duskwuff/8a75e1b5e5a06d768336c8c7c370f0f3 https://gist.github.com/duskwuff/8a75e1b5e5a06d768336c8c7c37...
patrickmeenan 2y ago
Absolutely, for the use cases where it makes sense. There are some examples here: https://github.com/WICG/compression-dictionary-transport/blob/main/examples.md https://github.com/WICG/compression-dictionary-transport/blo... In the web case, it mostly only makes sense if users are using a site for more than one page (or over a long time). Some of the common places where it can have a huge impact: - Delta-updating wasm or JS/CSS code between releases. Like the youtube player JavaScript or Adobe Web's WASM code. Instead of downloading the whole thing again, the version in the user's cache can be used as a "dictionary" and just the deltas for the update can be delivered. Typically this is 90-99% smaller than using Brotli with no dictionary. - Lazy-loading a site-specific dictionary for the HTML content. Pages after the first one can use the dictionary and just load the page-specific content (compresses away the headers, template, common phrases, logos, inline svg's or data URI's, etc). This usually makes the HTML 60-90% smaller depending on how much unique content is in the HTML (there is a LOT of site boilerplate). - JSON API's can load a dictionary that has the keys and common values and basically yield a binary format on the wire for JSON data, compressing out all of the verbosity. I expect we're still just scratching the surface of how they will be used but the results are pretty stunning if you have a site with regular user engagement. FWIW, they are not "pre-shared" so it doesn't help the first visit to a site. The can use existing requests for delta updates or the dictionaries can be loaded on demand but it is up to the site to load them (and create them). It will probably fall over if it gets hit too hard, but there is some tooling here that can generate dictionaries for you (using the brotli dictionary generator) and let you test the effectiveness: https://use-as-dictionary.com/ https://use-as-dictionary.com/
- jiggawatts 2y ago
  > if you have a site with regular user engagement. Ah, gotcha: this is a new Google standard that helps Google sites when browsed using Google Chrome. Everyone else will discover that keeping the previous version of a library around at build time doesn’t fit into the typical build process and won’t bother with this feature. Only Facebook and maybe half a dozen similar other orgs will enable this and benefit. The Internet top-to-bottom is owned by the G in FAANG with FAAN just along for the ride.

CaptainOfCoit 2y ago

I guess you should outline the cases you care the most about, for anyone to be able to answer if there is any material performance improvements.

hansvm 2y ago
The only requirements are serving a lot of the same "kind" of content, enough such (or for some other business reason) that it doesn't make sense to send it all at once, and somebody willing to spend a bit of time to implement it. Map and local geocoding information comes to mind as a decent application, and if the proposed implementation weren't so hyper-focused on common compression standards you could probably do something fancy for, e.g., meme sites (with a finite number of common or similar background images). Assuming (perhaps pessimistically) it won't work well for most sites serving images, other possibilities include: - Real-estate searches (where people commonly tweak tons of parameters and geographies, returning frequently duplicated information like "This historical unit has an amazing view in each of its 2 bedrooms"). - Expanding that a bit, any product search where you expect a person to, over time, frequently query for the same sorts of stuff. - Local business information (how common is it to open at 10am and close at 6pm every weekday in some specific locale for example). ... If the JS, image, and structural HTML payloads dwarf everything else then maybe it won't matter in practice. I bet somebody could make good use of it though.

therein 2y ago

Yup, we did experiment with SDCH at a large social network around 2015 and it didn't massively outperform gzip. Outperforming it required creating a pipeline for dynamic dictionary generation and distribution.

itsthecourier 2y ago
SDHC?
- morsch 2y ago
  Shared Dictionary Compression for HTTP https://en.m.wikipedia.org/wiki/SDCH https://en.m.wikipedia.org/wiki/SDCH

csswizardry 2y ago

Huge, huge improvements. I’ve been following this spec keenly. 1. https://compression-dictionary-transport-threejs-demo.glitch.me/ https://compression-dictionary-transport-threejs-demo.glitch... 2. https://compression-dictionary-transport-shop-demo.glitch.me/ https://compression-dictionary-transport-shop-demo.glitch.me...

fnordpiglet 2y ago

If you care about latencies or are on very low bandwidth or noisy connections preshared dictionaries matter a lot. By and large they generally always help but come with complexity so are often avoided in favor of a simpler approach whose compression is acceptable rather than optimal. But if there’s a clear and well implemented standard that’s widely adopted I would always choose preshared dictionaries. Likewise secure connections are hard and without TLS and other standards most people wouldn’t try unless they really needed it. But with a good standard and broad implementation it’s basically ubiquitous.

itsthecourier 2y ago

Bro, this stuff will be wild for our iot stuff

vitus 2y ago

The one example I can think of with a pre-seeded dictionary (for web, no less) is Brotli. https://datatracker.ietf.org/doc/html/rfc7932#appendix-A https://datatracker.ietf.org/doc/html/rfc7932#appendix-A You can more or less see what it looks like (per an older commit): https://github.com/google/brotli/blob/5692e422da6af1e991f9182345d58df87866bc5e/java/org/brotli/dec/DictionaryData.java https://github.com/google/brotli/blob/5692e422da6af1e991f918... Certainly it performs better than gzip by itself. Some historical discussion: https://news.ycombinator.com/item?id=19678985 https://news.ycombinator.com/item?id=19678985

duskwuff 2y ago
A more readable version of the Brotli dictionary: https://gist.github.com/duskwuff/8a75e1b5e5a06d768336c8c7c370f0f3 https://gist.github.com/duskwuff/8a75e1b5e5a06d768336c8c7c37...

patrickmeenan 2y ago

Absolutely, for the use cases where it makes sense. There are some examples here: https://github.com/WICG/compression-dictionary-transport/blob/main/examples.md https://github.com/WICG/compression-dictionary-transport/blo... In the web case, it mostly only makes sense if users are using a site for more than one page (or over a long time). Some of the common places where it can have a huge impact: - Delta-updating wasm or JS/CSS code between releases. Like the youtube player JavaScript or Adobe Web's WASM code. Instead of downloading the whole thing again, the version in the user's cache can be used as a "dictionary" and just the deltas for the update can be delivered. Typically this is 90-99% smaller than using Brotli with no dictionary. - Lazy-loading a site-specific dictionary for the HTML content. Pages after the first one can use the dictionary and just load the page-specific content (compresses away the headers, template, common phrases, logos, inline svg's or data URI's, etc). This usually makes the HTML 60-90% smaller depending on how much unique content is in the HTML (there is a LOT of site boilerplate). - JSON API's can load a dictionary that has the keys and common values and basically yield a binary format on the wire for JSON data, compressing out all of the verbosity. I expect we're still just scratching the surface of how they will be used but the results are pretty stunning if you have a site with regular user engagement. FWIW, they are not "pre-shared" so it doesn't help the first visit to a site. The can use existing requests for delta updates or the dictionaries can be loaded on demand but it is up to the site to load them (and create them). It will probably fall over if it gets hit too hard, but there is some tooling here that can generate dictionaries for you (using the brotli dictionary generator) and let you test the effectiveness: https://use-as-dictionary.com/ https://use-as-dictionary.com/

jiggawatts 2y ago
> if you have a site with regular user engagement. Ah, gotcha: this is a new Google standard that helps Google sites when browsed using Google Chrome. Everyone else will discover that keeping the previous version of a library around at build time doesn’t fit into the typical build process and won’t bother with this feature. Only Facebook and maybe half a dozen similar other orgs will enable this and benefit. The Internet top-to-bottom is owned by the G in FAANG with FAAN just along for the ride.