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

231–240 of 455 posts

Re: App sizes are out of control

#231

Post by dfox »

maxxxxx wrote: post #176
joshvm wrote: post #147

Earlier quoted context omitted.

This happens a lot, especially with dynamic linking. I have a project that uses Qt, OpenCV, CUDA, PCL and VTK - fairly standard stack for 3D imaging and visualisation. Since you normally need to bundle dependencies to account for different versions, this adds up quite fast. Qt adds 20MB for OpenGL, 15MB for the VC++ redist, about 30MB for other core libraries. Some stuff in OpenCV requires Nvidia's performance primit…

It's pretty ironic that dynamic linking's main motivation was to eliminate duplicate code and reduce code size. Deploy a DLL once, every software uses it and doesn't have to include it. Now it has turned out exactly the opposite way. If we went back to linking object code together we would get smaller sizes. Instead we have to include huge DLLs.

IIRC Windows has pretty involved infrastructure for deduplicating same executable images both in memory and on disk.

Re: App sizes are out of control

#232

Post by marcosdumay »

pandalicious wrote: post #213
babesh wrote: post #194

Earlier quoted context omitted.

For iOS, there are the shared libraries provided by the OS. UIKit, PhotoKit, etc... Shared libraries beyond that would bring the hell of version incompatibility. One need only look at Apple’s evolution of Swift where there still isn’t binary compatibility? Most people don’t want to crack open their phone and set paths so that their app has a version of Python that works with it. Also shared libraries can be giant sec…

It's pretty telling that Linux distros are pretty much the only end-user platforms where binary distribution and packaging is built around shared libraries. Pretty much everyone else (Windows/OS X/iOS/Android/etc) generally expect binaries to include their own bundled versions of 3rd party libraries. Lots of people have looked at this problem and most have opted against the shared library approach.

That's because Linux distros are more centralized that the Apple's walled garden. They just lack the walls, but are as much a garden as you can get.

Unless those platforms start distributing a huge number of libraries your software may decide do depend on, shared libraries won't take off on them.

Re: App sizes are out of control

#233

Post by moosingin3space »

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.

pcwalton's project Pathfinder (https://github.com/pcwalton/pathfinder) may eventually lead to an efficient GPU-based vector renderer, which would make this feasible.

Re: App sizes are out of control

#234

Post by swrobel »

jamieomatthews wrote: post #134
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?

I work on Amazon Prime Photos iOS app. It's currently 60mb in size, and a good chunk of that is the Swift runtime. Even the main Amazon shopping app is less than 100mb.

Those apps are standouts but generally Amazon iOS apps are appalling. Alexa is 78MB of pure UX hell.

Re: App sizes are out of control

#235

Post by dfox »

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.

The interesting part of this is that all this dynamism and dependence on runtime actually improves performance in comparison to C++. For example it is perfectly possible to implement objc_msgSend in portable C such that it is on modern superscalar and heavily cache dependent CPUs on average faster than C++-style virtual method call.

Re: App sizes are out of control

#236

Post by marcosdumay »

jamescostian wrote: post #127
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…

JavaScript people do not create libleftpad.so, they create libleftpad.o (metaphorically speaking), which will not clutter up your distribution, it will just clutter up some apps. I'd rather see 50 little files like libleftpad.o than 5 gigantic libraries. But I agree with what you're saying in the second paragraph, which actually sounds just like what my GP meant by using "Webpack to throw away what isn't used". Havin…

> I'd rather see 50 little files like libleftpad.o than 5 gigantic libraries.

And then you'll have to use software written in 50 different styles, with 50 different type and error conventions, with pieces that couple together or not at random.

Re: App sizes are out of control

#237

Post by abc_lisper »

jamieomatthews wrote: post #134
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?

I work on Amazon Prime Photos iOS app. It's currently 60mb in size, and a good chunk of that is the Swift runtime. Even the main Amazon shopping app is less than 100mb.

Wait. Do you have to include the runtime with the app? That seems backwards.

Re: App sizes are out of control

#238

Post by borplk »

twsted wrote: post #62

Most of the time it's the same reason why web pages are MBs in size today: lazy developers that uses a new library for every feature they need, without a deeper analysis of costs and benefits.

It's not just "lazy developers".

For most freelancers and contractors the economics of the market means most of the time you have to be lazy or you will lose the job to someone else.

Re: App sizes are out of control

#239

Post by marcosdumay »

richardwhiuk wrote: post #199
LeoNatan25 wrote: post #195

Earlier quoted context omitted.

Then don't move fast. It's as simple as that. Move at the pace that you can sustain a reasonably engineered app.

At which point everyone who moves fast will beat you.

Will them?

Amazon differential is not the quality of their app. Unless they create something really impressive some day, they can only lose customers by moving faster there.

Besides, none of those are small startups anymore. All of them have something to lose.

Re: App sizes are out of control

#240

Post by marcosdumay »

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 know, I'm not currently an Uber customer because their app is too big and I don't have enough spare space on my phone.

There were a few times already that I thought about using them, but couldn't install it right at the time.

Post reply on HN