3 ms·

I mean 4-5% the size for 10-100x the time is not worth it.

• swiftcoder 2y ago
  That's not actually so straightforward. You pay the 10-100x slowdown once on the compressing side, to save 4-5% on every download - which for a popular package one would expect downloads to be in the millions.
  • philipwhiuk 2y ago
    The downloads are cached. The build happens on every publish for every CI build.
    • realityking 2y ago
      Most packages don‘t publish every CI build. Some packages, such as Typescript, publish a nightly build once a day. Even then a longer compression time dosen‘t seem too bad.
    • swiftcoder 2y ago
      Caching downloads on a CDN helps offload work from the main server, it doesn't meaningfully change the bandwidth picture from the client's perspective.
• inglor_cz 2y ago
  As the author himself said, just React was downloaded half a billion times; that is a lot of saved bandwidth on both sides, but especially so for the server. Maybe it would make sense to only apply this improvement in images that are a) either very big or b) get downloaded at least million times each year or so. That would cover most of the savings while leaving most packages and developers out of it.
• bonzini 2y ago
  Assuming download and decompression cost to be proportional to the size of the incoming compressed stream, it would break even at 2000 downloads. A big assumption I know, but 2000 is a really small number.
• liontwist 2y ago
  It absolutely is. Packages are zipped once and downloaded thousands of times.