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

Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

openradar.me

Post reply on HN
Print view View original

41–50 of 142 posts

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#41

Post by defined »

DavidSJ wrote: post #27
adomanico wrote: post #20

Earlier quoted context omitted.

It does seem to be affecting the end user binary size: http://imgur.com/a/FEgQY These numbers were all around 60mb on Xcode 8.2.1

60 millibits is pretty small. (Pardon the joke, but while the "m" obviously means "M" from context, I really wish people -- especially computer engineers -- wouldn't say bits when they mean something eight times as large.)

I think you have a good point. The whole reason for standards (like SI units) is so that people don't need to guess or interpret. I don't get why this was downvoted.

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#43

Post by kibwen »

defined wrote: post #41
DavidSJ wrote: post #27

Earlier quoted context omitted.

60 millibits is pretty small. (Pardon the joke, but while the "m" obviously means "M" from context, I really wish people -- especially computer engineers -- wouldn't say bits when they mean something eight times as large.)

I think you have a good point. The whole reason for standards (like SI units) is so that people don't need to guess or interpret. I don't get why this was downvoted.

A bit isn't a divisible unit, so nobody is going to be confused as to whether "mb" stands for "millibits". As for the capitalization of "b", if we're going to be pedantic then we should say "Mo" for "megaoctets", since "byte" is, as far as IEEE standards are concerned, of ambiguous length. But I think we can trust people enough to not spend too long puzzling over whether "mb" means megabytes or megabits, just as we can trust them to assume that byte implies eight bits in this context.

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#44

Post by DannyBee »

adomanico wrote: post #20
DannyBee wrote: post #5

This appears to be bitcode. It probably means they just starting making use of more metadata or something that is now included in the bitcode. Bitcode also now deliberately trades off size vs speed and includes indexes used for LTO, etc. They could be including those. You should almost always expect bitcode to get beat by "llvm-dis|xz", because the goal of bitcode is not to be the most compact possible format, but in…

It does seem to be affecting the end user binary size: http://imgur.com/a/FEgQY These numbers were all around 60mb on Xcode 8.2.1

No, that's the wrong side of the store you are looking at :)

That's the size as uploaded by the developer, not downloaded to user.

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#45

Post by rsync »

kibwen wrote: post #43
defined wrote: post #41

Earlier quoted context omitted.

I think you have a good point. The whole reason for standards (like SI units) is so that people don't need to guess or interpret. I don't get why this was downvoted.

A bit isn't a divisible unit, so nobody is going to be confused as to whether "mb" stands for "millibits". As for the capitalization of "b", if we're going to be pedantic then we should say "Mo" for "megaoctets", since "byte" is, as far as IEEE standards are concerned, of ambiguous length. But I think we can trust people enough to not spend too long puzzling over whether "mb" means megabytes or megabits, just as we c…

"A bit isn't a divisible unit"

What ? Sure it is. When you measure the information content (or, the entropy) of a message, you very frequently get non-integer numbers of bits per (character/unit/message/whatever).

Written english, for instance, has 1.46 bits of information per character.

Or 146 cb.

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#46

Post by adomanico »

DannyBee wrote: post #44
adomanico wrote: post #20

Earlier quoted context omitted.

It does seem to be affecting the end user binary size: http://imgur.com/a/FEgQY These numbers were all around 60mb on Xcode 8.2.1

No, that's the wrong side of the store you are looking at :) That's the size as uploaded by the developer, not downloaded to user.

These numbers matched exactly to what is currently in the AppStore for the last release we have ready for sale

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#47

Post by kev009 »

rsync wrote: post #45
kibwen wrote: post #43

Earlier quoted context omitted.

A bit isn't a divisible unit, so nobody is going to be confused as to whether "mb" stands for "millibits". As for the capitalization of "b", if we're going to be pedantic then we should say "Mo" for "megaoctets", since "byte" is, as far as IEEE standards are concerned, of ambiguous length. But I think we can trust people enough to not spend too long puzzling over whether "mb" means megabytes or megabits, just as we c…

"A bit isn't a divisible unit" What ? Sure it is. When you measure the information content (or, the entropy) of a message, you very frequently get non-integer numbers of bits per (character/unit/message/whatever). Written english, for instance, has 1.46 bits of information per character. Or 146 cb.

That is expressing a ratio. A more concrete example, .46 a person doesn't exist even if that ratio is useful for expressing statistics.

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#48

Post by azakai »

DannyBee wrote: post #44
adomanico wrote: post #20

Earlier quoted context omitted.

It does seem to be affecting the end user binary size: http://imgur.com/a/FEgQY These numbers were all around 60mb on Xcode 8.2.1

No, that's the wrong side of the store you are looking at :) That's the size as uploaded by the developer, not downloaded to user.

If so, it seems very confusing that the header is "Install Size".

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#49

Post by DannyBee »

adomanico wrote: post #46
DannyBee wrote: post #44

Earlier quoted context omitted.

No, that's the wrong side of the store you are looking at :) That's the size as uploaded by the developer, not downloaded to user.

These numbers matched exactly to what is currently in the AppStore for the last release we have ready for sale

As it says below "You need to look at the download size on the end user device, not the binary size in iTunesConnect."

Is that what you are doing?

Because otherwise, it includes the bitcode size. (i don't pretend this makes sense. only that it is :P)

In any case, i would still bet more heavily on it being displayed wrong than anything else.

If i was to increase the binary size of first party apps at google by even 1%, there would be a mob with pitchforks at my desk in less than an hour.

I can't imagine apple is really different.

Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1

#50

Post by sneak »

LeoNatan25 wrote: post #29
sneak wrote: post #23

Earlier quoted context omitted.

I said explicitly in my comment that I don't think this is some grand conspiracy. I don't think Xcode makes big files to use up disk space. I think Apple just has little incentive across the entire ecosystem to use less storage or use storage more efficiently. Afaik bitcode is so that Apple can rebuild binaries for different target architectures (e.g. new models of phone, watch, et c) without source developer interac…

Bitcode does not allow cross-architectural builds. This is a common misconception. IR (& bitcode) includes architecture and platform-specific ABI. What it does allow is for better optimizations as the LLVM backend optimizer improves.

Ahh, good to know.
Post reply on HN