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

131–140 of 142 posts

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

#131

Post by entropy_ »

alimbada wrote: post #86
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…

The iOS Gmail app has increased in size to 140MB at the last update. I'm on a 16GB iPhone and I've noticed app sizes slowly increasing over the last two and a half years that I've had my phone. I have to keep an eye on app size to make sure I don't run out of space on my phone. I've already boycotted the Facebook app, but apps like Gmail are too important to uninstall. If it comes to it I'll be getting rid of a lot o…

The apple store binary format is really horrible when it comes to keeping the size down. Especially if you need to use libraries and whatnot. What it comes down to is this:

1 - The binary format itself isn't very efficient. Compressing it usually yields at least a 50% reduction in final size, often more

2 - Even though .ipa is a zipped format, there's no actual compression on the binary itself because it's encrypted before compression. I have no idea why they do this, I can't perceive any security benefit(Any jailbroken phone can be tooled to output the unencrypted binary. And you can bet anyone trying to reverse engineer your app will be using a jailbroken phone for their work)

Basically, if you're a large company with lots of apps and shared dependencies(Google, Facebook, etc...) doing the "right" thing and writing shared library code across projects ends up bloating your binary size immensely. And since binary size(rather than resources like images) dominate the final app size, you're in trouble if you want to keep app size down.

Source: I work on the iOS app for a music streaming service, despite our best efforts, our app downloadable size is ~35MB(~45MB installed size). Our android counterpart, almost effortlessly has the same app functionality with a 14MB downloadable package(they did some cleaning a while ago and got it down to 10MB at some point). Thing is, if we do proper compression(no binary encryption, single architecture) we end up with a 19MB .ipa file

PS: The compression issue doesn't affect installed size, but I believe the issue here is simply that (1) the binary format they're using is just too damn inefficient by default

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

#133

Post by hinkley »

btschaegg wrote: post #63
tempodox wrote: post #52

Earlier quoted context omitted.

While we're at it, one should use “Mi”, not “M”. M is still 1000 * 1000, while Mi is 1024 * 1024. That amount of sloppiness in any other engineering discipline would just finish you off immediately.

Agreed. Fun fact: Wolfram alpha understands Mebibytes, which is useful if you want to quickly convert between networking specs (say megabits) and "real" computer units. Then again, maybe doing more simple math by actually using one's brain wouldn't hurt either. :) Edit: And yes, I'm aware that you'll never get the converted speed of what is written on the network device's box. But sometimes it's nice to have an upper…

Many, many wire protocols use 5 bits of bandwidth to send 4 bits of information, for various reasons. So dividing by 10 gives you a better estimate.

Of course when gigabit became a thing, your practical throughput was more like 75 MBps for a very long time, and being off by 25% in capacity planning is a pretty big error (one I've seen numerous engineers make, and a few make both, which means you're off by 40%)

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

#134

Post by bwat49 »

JustSomeNobody wrote: post #104
alimbada wrote: post #86

Earlier quoted context omitted.

The iOS Gmail app has increased in size to 140MB at the last update. I'm on a 16GB iPhone and I've noticed app sizes slowly increasing over the last two and a half years that I've had my phone. I have to keep an eye on app size to make sure I don't run out of space on my phone. I've already boycotted the Facebook app, but apps like Gmail are too important to uninstall. If it comes to it I'll be getting rid of a lot o…

Features mostly. I mean, you seem to absolutely need the Gmail app. While I, too, have a Gmail account, I like the simplicity of the native mail app in iOS. I don't need any additional features. I get mail, I read mail, I can write mail.

I've never used the ios mail app, but in general gmail has a weird imap implementation that behaves wonky with a lot of mail clients so with gmail using the webmail or a gmail specific app is usually preferable.

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

#135

Post by eridius »

yAnonymous wrote: post #88
eridius wrote: post #72

Earlier quoted context omitted.

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…

>That's frankly a very offensive accusation to make Yeah. It's not like Apple had to settle lawsuits about batteries that seemed to be designed to break after a while. Oh, wait...

Oh wait what? I can't find any evidence of such a lawsuit. The closest I can find is a lawsuit over the fact that batteries are not user-replaceable.

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

#136

Post by flamedoge »

entropy_ wrote: post #131
alimbada wrote: post #86

Earlier quoted context omitted.

The iOS Gmail app has increased in size to 140MB at the last update. I'm on a 16GB iPhone and I've noticed app sizes slowly increasing over the last two and a half years that I've had my phone. I have to keep an eye on app size to make sure I don't run out of space on my phone. I've already boycotted the Facebook app, but apps like Gmail are too important to uninstall. If it comes to it I'll be getting rid of a lot o…

The apple store binary format is really horrible when it comes to keeping the size down. Especially if you need to use libraries and whatnot. What it comes down to is this: 1 - The binary format itself isn't very efficient. Compressing it usually yields at least a 50% reduction in final size, often more 2 - Even though .ipa is a zipped format, there's no actual compression on the binary itself because it's encrypted…

shame since shared library was suppose to be "DRY". Why not run compression and then encryption?

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

#137

Post by defined »

ce4 wrote: post #73
defined wrote: post #62

Earlier quoted context omitted.

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?

Ah crap, yes, I did. Got to stop this middle of the night posting...

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

#138

Post by defined »

srssays wrote: post #94
defined wrote: post #62

Earlier quoted context omitted.

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…

> 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, Not true anymore. OS X (and I assume iOS) reports sizes in power-of-10 units. If you think about it, it is really user-hostile to express file sizes as powers-of-two. Who can remember that a "GiB" is 1073741824 bytes?

I didn't know OS/X used the decimal prefixes, but that just means it's less true, not untrue. There are still many more systems out there that use the binary prefix. I imagine most *nix, and not sure about Windows. And RAM is still power of 2.

I don't think it's terribly user hostile to express sizes as powers of two when you work with these kinds of numbers for a living, especially when it's near the bare metal (Erlang binary data type FTW!)

But I do think it's user hostile to have two different units depending on what you're looking at. If it were all decimal or all binary, it would be much easier.

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

#139

Post by defined »

tripzilch wrote: post #121
ldev wrote: post #99

Earlier quoted context omitted.

Because we solve practical problems, and do not nit pick of what is technically correct. We are not drones and easily understand that in this context it's megabytes. Just look at all that "technically it's mebibytes bla bla bla" in replies. No one cares. Write some code. Or better - go outside.

space launches have crashed because of confusion over standard units. in that case it was confusion between metric and certain fantasy engineering units, but an error of 1000/1024 will cause troubles just as badly. so with that attitude maybe don't write that code, and better stay inside or a rocket might fall on your head. but for serious, that correction probably has taught more than 10 people the difference betwee…

This. Thank you.

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

#140

Post by Joky »

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 impacts only the bitcode and not the final binary AFAIK. The issue is with debug-info not being stripped out completely as expected. It comes from a change from LLVM upstream that was made (in 3.9) to keep source locations for providing better optimization diagnostics. It interacts badly with the debug info stripping and apparently wasn't caught. It is used by the optimizer to tell you e.g. that a specific loop can't be vectorized. See http://llvm.org/devmtg/2016-11/Slides/Nemet-Compiler-assiste... for more details about how it's used.

https://twitter.com/JokerEph/status/847512069209432064 https://twitter.com/JokerEph/status/847513808570523653 https://twitter.com/JokerEph/status/847514189929234432

Post reply on HN