Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My failed attempt to shrink all NPM packages by 5%

evanhahn.com

Post reply on HN
Print view View original

241–250 of 253 posts

Re: My failed attempt to shrink all NPM packages by 5%

#241

Post by Someone »

DannyBee wrote: post #231
Someone wrote: post #217

Earlier quoted context omitted.

> the standard compression level for rpms on redhat distros is zstd level 19 > The only reason to use zstd is because you want fairly good compression, but fast I would think having fast decompression is desirable, too, especially for rpms on redhat distros, which get decompressed a lot more often than they get compressed, and where the CPUs doing decompression may be a lot slower than the CPUs doing the compression.…

Let me start by reiterating - zstd is a great option. I think zstd level 5-10 would have been an awesome choice. I love zstd - it is a great algorithm that really hits the sweet spot for most users between really fast and good compression, and very very fast decompression. I use it all the time. In this case, yes, zstd has faster decompression , but xz decompression speed is quite fast, even before you start using th…

> So they are doing all this single threaded for no particular reason - as far as i can tell, this is a bug in this well thought out change

Could be because they want reproducible builds.

Re: My failed attempt to shrink all NPM packages by 5%

#242

Post by avodonosov »

hinkley wrote: post #111
avodonosov wrote: post #13

My experiment on how to reduce javascript size of every web app by 30-50% : https://github.com/avodonosov/pocl Working approach, but in the end I abandoned the project - I doubt people care about such js size savings.

I got measurable decreases in deployment time by shrinking the node_modules directory in our docker images. I think people forget that, when you’re copying the same images to dozens and dozens of boxes, any improvement starts to add up to real numbers.

In this approach the size of deployment bundles / images is not necessarily reduced.

Reduced is the size of javascript loaded into the end user's browser.

Re: My failed attempt to shrink all NPM packages by 5%

#243

Post by avodonosov »

fwip wrote: post #76
tyre wrote: post #23

Earlier quoted context omitted.

Size savings translates to latency improvements which directly affects conversion rates. Smaller size isn’t about reducing costs but increased revenue. People care.

Note that this proof-of-concept implementation saves latency on first load, but may add latency at surprising points while using the website. Any user invoking a rarely-used function would see a delay before the javascript executes, without the traditional UI affordances (spinners etc) to indicate that the application was waiting on the network. Further, these secretly-slow paths may change from visit to visit. Many…

Only the first user who hits a rarely used execution point may experience the noticeable latency, if he also has slow internet, etc.

As soon as the user executes a rarely used function, the information is about this fact is sent to the server and it includes this function into the active set to be send to future users.

In the video I manually initiate re-generation of the "active" and the "rest" scripts, but the most primitive MVP was supposed to schedule re-generation of the scripts when receiving info that some previously unseen functions are executed in browser.

Obviously, if the idea is developed further, the first user's experience may also be improved - a spinner shown. Pre-loading the inactive set of functions in background may also be considered (pros: it allows to avoid latency for users ho invoke rare functionality, cons: we lose the savings of the traffic and browser memory and cpu for compiling the likely unneded code).

(BTW, further development of the idea includes to splitting the code more granularity than just "active" / "inactive". E.g. active in the first 5 seconds after opening the page loaded immediately, likely to be active soon, active but rarely called - the later two these parts definitely need to be loaded in background)

Re: My failed attempt to shrink all NPM packages by 5%

#244

Post by avodonosov »

dagelf wrote: post #16
avodonosov wrote: post #13

My experiment on how to reduce javascript size of every web app by 30-50% : https://github.com/avodonosov/pocl Working approach, but in the end I abandoned the project - I doubt people care about such js size savings.

Wdym?? 50% is a big deal

Why big deal?

50% is just a big O of the original size :)

If we consider overall Internet traffic, which is dominated by video and images, the size of javascript transmitted is negligible.

Savings of memory and cpu for end user's browser? Maybe, but our software at all layers is so bloated, without need, just carelessly, that I'm not sure working of such javascript savings is useful - any resources saved will be eaten by something else immediately.

For an application developer or operator, the 50% savings of javascript size are probably not worth dealing with some tool that dynamically prunes the app code, raising questions about privacy and security. I though through the security and privacy questions, but who would want to even spend attention on these considerations?

As I mention in the README at github, a Microsoft researcher investigated the same approach earlier, but Microsoft haven't taken it anywhere.

There was a commercial company offering this approach of javascript minification as a product, complete product. As well as other optimizations, like image size, etc. Their proxy embedded special "agent" code into the app which inspected the device and reported to server what image sizes are optimal for user, what js functions are invoked. And the server prepared optimized versions of app for various devices. Javascript was "streamed" in batches of only functions needed by the app.

Now the company is dissolved - that's why the website is unavailable. Wikipedia says they were bought out by Akamai - https://en.wikipedia.org/wiki/Instart. But I don't see any traces of this approach in the today's Akamai offerings.

I contacted several companies, in CDN business and others, trying to interest them in the idea and get very modest funding for a couple more months of my time to work on this (I was working on this in the end of a long break from payed work and was running out of savings). Didn't find anyone ready to take part.

This all may be signs that possibility of such an optimization is not valuable enough for users.

Re: My failed attempt to shrink all NPM packages by 5%

#245

Post by DannyBee »

Someone wrote: post #241
DannyBee wrote: post #231

Earlier quoted context omitted.

Let me start by reiterating - zstd is a great option. I think zstd level 5-10 would have been an awesome choice. I love zstd - it is a great algorithm that really hits the sweet spot for most users between really fast and good compression, and very very fast decompression. I use it all the time. In this case, yes, zstd has faster decompression , but xz decompression speed is quite fast, even before you start using th…

> So they are doing all this single threaded for no particular reason - as far as i can tell, this is a bug in this well thought out change Could be because they want reproducible builds.

First, here is no data or evidence to suggest this is the case, so not sure why you are trying to make up excuses for them?

Second, zstd is fully deterministic in multithreaded cases. It does not matter what threading you select, it will output byte for byte identical results.

See a direct answer to this question here: https://github.com/facebook/zstd/issues/2079

I believe all of their compressors are similarly deterministic regardless of number of threads, but i admit i have not checked every one of them under all conditions.

If they had questions, they could have, you know, asked, and would have gotten the same answer.

But that just goes back to what i said - it does not appear this change was particularly well thought out.

Re: My failed attempt to shrink all NPM packages by 5%

#246

Post by avodonosov »

philipwhiuk wrote: post #79
avodonosov wrote: post #13

My experiment on how to reduce javascript size of every web app by 30-50% : https://github.com/avodonosov/pocl Working approach, but in the end I abandoned the project - I doubt people care about such js size savings.

How do you evaluate call usage?

By instrumenting the code so that the function records the fact that it is being invoked.

Then the info about the called functions is sent back to the server.

(Only the functions never seen to be called are instrumented, the known active functions are not instrumented).

Re: My failed attempt to shrink all NPM packages by 5%

#247

Post by avodonosov »

vlovich123 wrote: post #123
fwip wrote: post #76

Earlier quoted context omitted.

Note that this proof-of-concept implementation saves latency on first load, but may add latency at surprising points while using the website. Any user invoking a rarely-used function would see a delay before the javascript executes, without the traditional UI affordances (spinners etc) to indicate that the application was waiting on the network. Further, these secretly-slow paths may change from visit to visit. Many…

> without the traditional UI affordances (spinners etc) to indicate that the application was waiting on the network. This part is obviously trivially solvable. I think the same basic idea is going to at some point make it but it’ll have to be through explicit annotations first and then there will be tooling to automatically do this for your code based upon historical visits where you get to tune the % of visitors tha…

I agree with most of your comment, but don't get what you mean about explicit annotations.

Note that most of the unused code is located in libraries, not in the app code directly.

Re: My failed attempt to shrink all NPM packages by 5%

#248

Post by vlovich123 »

avodonosov wrote: post #247
vlovich123 wrote: post #123

Earlier quoted context omitted.

> without the traditional UI affordances (spinners etc) to indicate that the application was waiting on the network. This part is obviously trivially solvable. I think the same basic idea is going to at some point make it but it’ll have to be through explicit annotations first and then there will be tooling to automatically do this for your code based upon historical visits where you get to tune the % of visitors tha…

I agree with most of your comment, but don't get what you mean about explicit annotations. Note that most of the unused code is located in libraries, not in the app code directly.

split async function handle_button_press() { … }

This would cause the bundler to inject a split point & know how to hide that + know what needs bundling and what doesn’t. GWT pioneered almost 20 years ago although not a fan of the syntax they invented to keep everything running within stock Java syntax: https://www.gwtproject.org/doc/latest/DevGuideCodeSplitting....

Re: My failed attempt to shrink all NPM packages by 5%

#249

Post by fergie »

atiedebee wrote: post #20
fergie wrote: post #12

Props to anyone who tries to make the world a better place. Its not always obvious who has the most important use cases. In the case of NPM they are prioritizing the user experience of module authors. I totally see how this change would be great for module consumers, yet create potentially massive inconvenience for module authors. Interesting write-up

I think "massive" is overstating it. I don't think deploying a new version of a package is something that happens many times a day, so it wouldn't be a constant pain point. Also, since this is a case of having something compressed once and decompressed potentially thousands of times, it seems like the perfect tool for the job.

Module authors generally have fairly large test suites which are run often- sometimes on each file save. If you have a 1 or 2 second build script its not a huge deal. If that script starts taking 30-60 seconds- you have just hosed productivity. Also you have massively increased the load on your CI server- possibly bumping you out of a free tier.

The fix would then have to be some variation of:

a) Stop testing (so often)

b) Stop bundling before testing

c) Publish to a different package manager

- all of which would affect the overall quality and quantity npm modules.

Re: My failed attempt to shrink all NPM packages by 5%

#250

Post by atiedebee »

fergie wrote: post #249
atiedebee wrote: post #20

Earlier quoted context omitted.

I think "massive" is overstating it. I don't think deploying a new version of a package is something that happens many times a day, so it wouldn't be a constant pain point. Also, since this is a case of having something compressed once and decompressed potentially thousands of times, it seems like the perfect tool for the job.

Module authors generally have fairly large test suites which are run often- sometimes on each file save. If you have a 1 or 2 second build script its not a huge deal. If that script starts taking 30-60 seconds- you have just hosed productivity. Also you have massively increased the load on your CI server- possibly bumping you out of a free tier. The fix would then have to be some variation of: a) Stop testing (so oft…

In that case, I don't understand why you would bundle the package every time you run tests. What does that do?
Post reply on HN