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

71–80 of 142 posts

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

#71

Post by rurban »

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…

I assume they added more bitcode so they can add better IPO jit optimizations in swift, across modules. Or optimize per target on those small devices.

bitcode is already compressed.

But the regression is huge, there needs to be a command-line switch to turn that off.

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

#72

Post by eridius »

sneak wrote: post #17

Apple charges $1200 to upgrade the latest touch bar rMBP from 512GB to 2TB of flash. Let's not forget that they are a hardware vendor. I don't think it's some grand conspiracy theory, but the interests of the vendor and of the user are not precisely aligned when it comes to efficient usage of storage. (The lack of stripping applications of their alternate language content on install/download also comes to mind.)

No, Apple is not intentionally wasting your storage. That's frankly a very offensive accusation to make.

As for alternate language content, honestly that stuff doesn't take up very much space, and stripping it would break the code signature. The only way Apple could strip that is if they perform the equivalent of App Thinning based on a list of languages you specify when downloading the binary from the App Store (and even that wouldn't apply to downloading non-MAS apps).

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

#73

Post by ce4 »

defined wrote: post #62
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…

Well, no. If we're going to be pedantic, we should say MiB (mebibytes), because file sizes on disk are expressed in multiples of powers of 2, but the SI prefixes are multiples of 10. So a 1 megabyte file (as reported by the file system) is actually 1048576 bytes, which technically - sorry, I mean pedantically - speaking, is 1 mebibyte. To make matters worse, disk manufacturers use the decimal prefixes, so our nice 1…

You probably meant 1TB to be 931 Gibibytes, didn't you?

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

#74

Post by drdeca »

kev009 wrote: post #47
rsync wrote: post #45

Earlier quoted context omitted.

"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.

I think "gaining half a bit of information" about something can correspond to stuff that lets you update your probability distribution about it?

I'm not sure.

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

#75

Post by DannyBee »

lawnchair_larry wrote: post #68
DannyBee wrote: post #49

Earlier quoted context omitted.

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%…

I can't imagine anywhere besides Google that would actually notice or care about that.

Gonna disagree: Pretty much anywhere that doesn't generate shitty apps cares about even small size regression

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

#76

Post by DannyBee »

techdragon wrote: post #55
DannyBee wrote: post #49

Earlier quoted context omitted.

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%…

I'm not sure the same can be assumed for Apple based on several things such as internal secrecy, differing organisational hierarchies, their willingness to focus on things that aren't tangible metrics like end user file download size. Between the org and culture differences I'm just not so sure Apple can be safely assumed as similar as you expect.

None of the things you mention change the fact that if you increase the IOS system image size by 3x, it will likely no longer fit in the default firmware partition :)

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

#77

Post by JCharante »

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.

You can downvote?

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

#78

Post by alien3d »

0x0 wrote: post #51
alien3d wrote: post #40

Earlier quoted context omitted.

if so okay, but still i do confuse with the limitation of 100mb.Sometimes facebook apps can update more then 100 mb and some apps cannot update over 100 mb.

That's probably because the app store may offer a delta update patch instead of a full download.

i prefer to knew more about it.. but seem here down vote making me sad those coward downvoter.. maybe i will close this account..

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

#79

Post by pjmlp »

LeoNatan25 wrote: post #33
jevinskie wrote: post #32

Earlier quoted context omitted.

I would imagine that with enough engineering effort, a cross-architecture "porting" of IR would be feasible. I doubt Apple will bother to do that when they can just force developers to rebuild and republish lest they get left out of the App Store.

Outside of a Java-style high-level VM, cross-platform cross-architecture in the C world requires compilation. You cannot use what is not there. When compiling a C language, macros are used to determine architecture and platform, and extra code is simply not compiled. The most simplest of examples is endianness handling, which would be totally broken if Intel-compiled code is automagically made to run on arm.

> Outside of a Java-style high-level VM, cross-platform cross-architecture in the C world requires compilation.

Kind of.

On IBM i, C compiles to TIMI bytecode just like everything else. For producing actual native code directly from the compiler you need the Metal C compiler, or the POSIX compatibility environment (PASE).

The TenDRA C and C++ compilers also used bytecode (TenDRA Distribution Format).

http://www.tendra.org/tdf-guide

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

#80

Post by akvadrako »

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.

Or to express it another way, a variable with 3 possible states has 0.5 bits more capacity than one with 2.
Post reply on HN