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

App sizes are out of control

trevore.com

Post reply on HN
Print view View original

221–230 of 455 posts

Re: App sizes are out of control

#221

Post by mikeash »

Retric wrote: post #217
saagarjha wrote: post #201

Earlier quoted context omitted.

> Interesting, I find that surprising due to the overhead involved. Due to the frequency of this, objc_msgSend (which handles dynamic method calls) is hand-written in assembly, with caching and "fast paths" to improve speed. The overhead can usually be brought down to that of a virtual function call in C++.

That's like saying shooting yourself in the foot only hurts the first time. But, it's probably not a major performance issue in practice.

That's the thing about performance. If you do something a million times, it's usually OK if the first time takes a thousand times longer than the fast case, as long as subsequent times are fast.

Look at how much code is written in Ruby and Python. Their method dispatches are way slower. To put it in perspective, it takes CPython about an order of magnitude longer to add two numbers together than it takes Objective-C to do a dynamic method dispatch.

Re: App sizes are out of control

#224

Post by dfox »

pm215 wrote: post #166
cyphar wrote: post #70

Earlier quoted context omitted.

I don't think that's the right solution to the problem. Nobody wants libleftpad.so, and as someone who works on a distribution the very concept is horrific (making distribution packages for every three-line package does not make anyone happy). What I think GP was arguing for is that you have libstring.so which you can strip down to just having leftpad or w/e with Kconfig or similar configurations (preferably at link…

If you want "just pull in the things I use" you can already get that by having a static library, and if you were going to be shipping a private copy of the .so file in your app then surely you would be better off with a static library -- you don't get any of the benefits of the DLL (sharing with other apps, can update the DLL without shipping a new copy of the whole app), so why pay the cost of it? (If you link again…

Probably only widely used static C library with fine grained dependency tracking is glibc. The source code structure required for that is probably one of the major reasons for people to call glibc's source code unreadable and/or unmaintable.

Re: App sizes are out of control

#225

Post by ringaroundthetx »

In several interviews I've been questioned about the importance of my contributions throughout my entire career because the apps sizes were so small (typically 8 - 12 mb)

When asked it was clear they'd already made up their mind, and discussions about optimizations, how the app actually did anything, MVC, MVP or SVGs didn't change that.

And thats how you have large apps!

Re: App sizes are out of control

#226

Post by Aqua_Geek »

vkou wrote: post #150
Apocryphon wrote: post #120

It's pretty rich how these companies are well known for the rigor they apply to interviewing candidates on technical subjects, yet actually drop the ball in production with poor engineering like this. Where does that rigor go after the interviews are done? Are there any examples of well-known apps from large organizations that aren't excessively large in size?

Because the customers are the ones who are paying for that inefficiency, not the company. You can bet that those companies' infrastructure is optimized to hell and back.

> You can bet that those companies' infrastructure is optimized to hell and back.

You'd be surprised. (Source: I work at a unicorn.)

Re: App sizes are out of control

#228

Post by CaptSpify »

chubot wrote: post #78
trevor-e wrote: post #64

Earlier quoted context omitted.

Sorry for the extra bandwidth, forgot to optimize the images.

Well that's your answer to your question. You forgot to optimize the images, because with your test environment, you don't notice it. If you were testing over a dial-up connection, you would notice it. Same with app writers. They forgot to optimize their app because they're testing it on the latest and greatest phones on their home network (or a corporate network which is blazing fast). If they tested on a low-end ph…

I used to work at a shop that ran a 1.5 mbps dsl line, and a ~5 year old, cheap, slow computer. If their code worked on that, it would work on any of our customer's machines.

I wish devs would still test like that. Sure, your app works fine in downtown SF on the newest phone, but try using it in Nowherseville, TN, on a phone that is more than a couple years old. I bet a lot of user frustration comes from dealing with that.

Re: App sizes are out of control

#229

Post by mahyarm »

mfabbri77 wrote: post #180
vladdanilov wrote: post #159

The situation is messy. Take Facebook.app. The reported size on the App Store is 377MB, the distributed .ipa is 241MB. But it is a universal app which includes fat binaries arm_v7 and arm64 and all the graphics 1x, 2x and 3x. App Thinning halves that size for end users. Yet the App Store reports the full size. There's more. App Store also provides some sort of delta updates [1], which save a lot bandwidth, but failin…

I was wondering why not use SVG (or any other vector file format) files and render all the graphic on the device, instead of including tons of PNG at various resolutions.

Raster images are still faster and often you can make your png images very small and do stretching.

OTOH, people do vector stuff for many things, it's just they typically don't use SVG but something more efficient. XML parsing is not lightweight compared to a binary format or some sort of vector -> code translator speed wise.

Post reply on HN