Repository navigation
28% binary size increase from v6.1.0 to v6.2.0 (with default configure options) #6860
Description
Activity
- changed the title
[-]28% binary size increase from v6.1.0 to v6.2.0[/-][+]28% binary size increase from v6.1.0 to v6.2.0 (Alpine Linux only?)[/+]on May 18, 2016 Hmmm, I just checked using the official node images, and there doesn't seem to be the same discrepancy. My bad.
$ docker run node:6.1.0 ls -l /usr/local/bin/node -rwxrwxr-x 1 500 500 27368828 May 5 21:41 /usr/local/bin/node $ docker run node:6.2.0 ls -l /usr/local/bin/node -rwxrwxr-x 1 500 500 27459658 May 17 19:40 /usr/local/bin/nodeI'll dig into whether something's changed on my end.
But does anyone have any idea why this may have happened on Alpine (musl)?
- addedquestionIssues asking questions about Node.js.Issues asking questions about Node.js.buildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.
on May 18, 2016 Did you upgrade your toolchain (compiler, linker, binutils) in between?
@bnoordhuis I don't think this could be the cause – building v6.1.0 with the same toolchain as I used for v6.2.0 results in the same filesize reported above (21.3MB for v6.1.0)
Are (or were) the official node builds using any configure flags in particular?
I'm betting this is because of the recent inclusion of small-icu data. @mhart Did you try building with
--without-intland seeing if that reduces the binary back to about what it was before?@mscdex were the official builds including this ICU stuff before? Just wondering why they didn't change (apparently)
@mhart I don't believe so. I think node v6.2.0 is the first version to include icu data by default and IIRC the precompiled binaries use defaults.
Looking at the commits that went into v6.2.0, icu is the only thing that could have impacted binary size. I don't know if there is an easy way to double check that there is no icu data in the binary....
stringsperhaps?@mscdex I'm pretty sure our official builds always came with icu
just double checked and v4.4.4 has icu 56.1node -e "console.log(process.versions)" | grep icu@thealphanerd Ah ok.
Yeah, that would be it then.
$ docker run node:6.1.0 node -e "console.log(process.versions)" | grep icu icu: '56.1', $ docker run mhart/alpine-node:6.1.0 node -e "console.log(process.versions)" | grep icu # nothing $ docker run mhart/alpine-node:6.2.0 node -e "console.log(process.versions)" | grep icu icu: '57.1',Ugh... now need to figure out if I explicitly exclude it... considering it was before...
Is there some documentation somewhere about how the official builds are configured? I always just assumed they used defaults and didn't pass anything special to
./configure@mhart you will need to include
./configure --without-intlThat is unfortunately broken on v6.2.0, but the thread this conversation started in has been landed on master to fix it. You can either float that patch, or wait for next weeks release.
One thing worth mentioning, v4.x does not have that flag... so if you have tooling you are going to likely have to introduce a way to check which version is being built
@thealphanerd yeah I'm just trying to figure out if that's the right thing to do now.
Hard to know whether it's best to be consistent with the way it's been built up until now – or consistent with the way the official node image is built.
I might split out a new bunch of docker tags
*-icuor something like that – if ppl really want the builds with icu stuff- changed the title
[-]28% binary size increase from v6.1.0 to v6.2.0 (Alpine Linux only?)[/-][+]28% binary size increase from v6.1.0 to v6.2.0 (with default configure options)[/+]on May 18, 2016 Yes, ICU has been included by default since v4 (and v0.12). There was an updated version of ICU that represents a bit of a bump up in size. /cc @srl295
just to clarify... it was included by default in our builds... the default
./configureflag in the past did not include icuI think I'll just add
--without-intlpost v6.2.0 to my Alpine images – it'll have to be an anomalous patch version and hopefully no one will be relying on its ICU support suddenly!I haven't had an issue posted at https://github.com/mhart/alpine-node yet about the lack of ICU up until v6.2.0, so hopefully users of the image will be fine with that going forward.
Going to close this as the root cause has been found. Other distributions relying on the default
./configurebehaviour will run into the same thing I guess – hopefully they're aware enough of it (eg http://git.alpinelinux.org/cgit/aports/tree/main/nodejs/APKBUILD )@mhart fwiw there was an extended period of time where we were shipping binaries from the NodeSource Linux repos without Intl and it wasn't picked up for a long time. I don't think Intl features are in common use anywhere yet and when they do I would hope that there's some awareness that it's not an always-available thing.
That said, the V8 team plans on making ICU a non-optional dependency: Proposal to switch from Unibrow to ICU in V8
@bnoordhuis is that the same ICU (does that even make sense?) as what Node.js is currently bundling? Will the Node build change to just use v8's ICU, or is it already doing that, or does that question not even make sense?
is that the same ICU (does that even make sense?) as what Node.js is currently bundling?
Yes.
Will the Node build change to just use v8's ICU, or is it already doing that, or does that question not even make sense?
It's the other way around: V8 uses the copy of ICU that's bundled with node.
Ah, gotcha. Ok. I'm guessing that'll happen in some future (major?) v8 bump. I'm kinda tempted to keep it out of the (Alpine) v6.x builds – I know it's not technically a "breaking" change from v6.1 to v6.2, but the size jump was a little unexpected.
Anyway, thanks for the info @bnoordhuis
- addedi18n-apiIssues and PRs related to Node.js internationalization support.Issues and PRs related to Node.js internationalization support.
on Oct 25, 2016
The node binary has increased in size quite noticeably from v6.1.0 to v6.2.0. Incremental size increases have been happening as more functionality's been added obviously, but this is quite a jump for a minor release.
(28.48% increase)
When compiled with
--fully-static:(22.36% increase)
Is this just something we have to live with, or has something gone awry here?