211–220 of 455 posts
Earlier quoted context omitted.
This would be true if the entirety of the library was used by the application. Wouldn't the linker throw out anything unused?
A lot of modern runtimes don't have linkers. With Java, C# and JavaScript you get the whole library. There is no elimination of unused code.
Earlier quoted context omitted.
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.
Because different graphics are shown are different resolutions, rather than purely scaling a highly detailed 1024x1024 SVG down to 128x128.
Vectors don't have pixels.
Earlier quoted context omitted.
I'm as far to mobile development as I can be but is there no shared libraries on those platforms ? Other than the environment provided ones, isn't it possible to bundle some dynamically loaded libraries that can be shared by multiple apps ? Makes absolutely no sense for each application to implement it's own web browser/runtime. Can't believe we are constantly reinventing the wheel again.
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…
Is anyone else worried about the massive amounts of bundled third-party libraries that come with each app from a security, rather than a size, perspective? What happens when such a library receives a security patch? AFAIK it's up to each developer to keep all bundled libraries up-to-date, which means that, realistically, everyone is shipping lots of vulnerable stuff and they don't even know it. "This shirt is dry cle…
The idea is that because it's all open sourced, all the vulnerabilities will be found and patched. But more often than not you just end up missing the small notification from the maintainers telling you to update.
And supposedly we don't need PWAs according to Apple...
We're finally getting back to that original vision.
I never understand where this increasing size comes from. For videos or hi-res photographs, I understand. There is however no reason that code, either compiled to a binary format or in a textual format, uses so much data. Heck, the memoirs of Casanova spans 3000 pages, and is 6,5 MB. People don't understand how incredibly large a megabyte is for simple code. Surely the 275 MB isn't all useful data (I wonder what comp…
Anyway, probably millions of lines of code, 99.9% of which I didn't call. There is a tool for stripping code that will not be called, and I reduced my apk's from ~20MB to ~1MB, although I wound up turning it off in the end because it was not trivial to enable correctly. (I was linking 3rd party binary libraries into my app which complicated things)
Earlier quoted context omitted.
Interesting, I find that surprising due to the overhead involved. In most languages calling functions via string names is very expensive. PS: Do you have an example?
> 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++.
Earlier quoted context omitted.
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.
I'm guessing but it seems logical that phones are not the place you want to do extra graphics rendering if you don't have to.
Earlier quoted context omitted.
Could it be that whenever coders today need some fairly trivial functionality, they tend to go out and find a library that contains it. So you end up with lots and lots of libraries where only a tiny bits of them are used. Just a hypothesis though.
I think this is likely the biggest culprit. Another user pointed out an analysis of the Facebook app: http://blog.timac.org/?p=1707 Most of it is actual code - not assets. For some types of apps (see: games) assets do take up a significant portion of total size, but for most everyday apps bloat by code over-inclusion is likely a bigger problem than asset-bloat. I wonder if it's possible to get major open-source libs…
Also I think we, as programmers, have taken the "don't reinvent the wheel" principle too far. The idea is to use 3rd party code to (1) save time writing, (2) reduce the risk of bugs, and (3) lower the maintainance burden.
But this makes sense only if the benefits outweigh the corresponding costs of integration, which also (1) takes time, (2) might be done wrong (especially because you don't understand the part you added), and (3) creates a maintainance burden. Of these, only #1 is solved when your development environment makes adding new libs quick and easy.
Earlier quoted context omitted.
There are many reasons why apps are so big, but I think you are right about a major part of the problem. Development environments these days make it very easy to add in third party libraries for very little effort. At a previous job we had a monolithic java server that ended up at over 350Mb of compiled code simply because each development team had imported whatever libraries they thought they needed. In some cases,…
How did they get multiple versions of the same library to work together? Java loads things via the class path so I would have thought that would cause some sort of error.