Why is stdlib size so large?

[orenbh1]

jStat size is only 120KB and it includes many distributions, among other features. However, it doesn't provide an option to link only to a specific distribution.

Considering linking to stats-base-dists-t.js directly, I expected a size around 5KB-10KB. However, the actual size is 83KB.
If taking only the quantile, the size of stats-base-dists-t-quantile.js is 77KB

[kgryte]

@orenbh1 You'll need to provide additional details on how you calculated the sizes.

One aspect of @stdlib/stats-base-dists-t-quantile, in particular, is that we use a more robust algorithm for computing the inverse of the lower incomplete beta function. Compare our implementation (based on Boost) to that of jstat. So, I'd probably expect that our implementation may be a bit heftier than other libraries, as we typically opt for algorithms which are more accurate and will minimize error accumulation in subsequent operations.

[orenbh1]

Thanks @kgryte
I compared the size of the minified files on my disk.

[kgryte]

Thanks for circling back. Looking at the UMD bundle, the bundle is around 76 kb, but, as I mentioned, this is largely due to needing a robust implementation of the inverse incomplete beta function.

[orenbh1]

Dear @kgryte,

Thanks for the fast reply and sorry for the late response.
It is great to know that stdlib-js implementation for inverse t distribution is more accrued :)

I did a random comparison, and the most significant distinction between stdlib-js and jstat for inverting t was that only the first six digits after the decimal point were identical.

For a webpage, speed is important, and there is a significant advantage if the JavaScript file is smaller. The minified jstat is only 72KB and includes many distributions and tests. On the other hand, stdlib is more accurate. Now, I'm not sure which one to use :)
Anyway, more options are always better, and I like the way stdlib-js is organized :)

[kgryte]

Re: speed is important. We recognize this, but we also recognize that, while there will always be room for improvement, some implementations will always be more involved (read: require more bytes) than others.

As a general principle, users benefit the more they use stdlib because the more they use stdlib the more underlying implementations are shared.

In contrast, if a user picks and chooses various non-stdlib npm packages, there will likely be duplication of similar logic, leading to eventual larger bundle sizes than if stdlib had been used exclusively.

In short, there will always likely be a bundle size penalty when consuming one-off stdlib packages, just because of our level of rigor and comprehensiveness, but that penalty is significantly reduced and eventually inverted once you consume more and more of the project, as you're allowing stdlib packages to reuse more and more shared infrastructure and underlying implementations.