2014-11-25 17:24 GMT+01:00 Esteban Lorenzano <[email protected]>: > and btw… spur format will consume more memory. >
Why ? If I remember correctly the first Squeak image generated was 3% smaller. How bigger is the spur Pharo image compared to the regular image ? but yet, memory management will be a lot more efficient so… :P > > Esteban > > On 25 Nov 2014, at 17:22, Esteban Lorenzano <[email protected]> wrote: > > I think is you who is confusing apple and oranges. > at first time, a check of my iphone shows that more than half of the apps > I use are bigger than 30m (and 30% of them are regularly 50m and more… I > even have apps 500+)… and those applications are the ones that I use the > most. > no games there. They are: fb, mail, whatsapp, keynote, etc. (ah, no… there > is a sudoku there.. 60m :P) > > Now… size occupied is not the same as size in memory. This is the size > occupied by all app (binaries + data) and I don’t really know of how much > that would be for real (I know facebook eats a lot)… Pharo, in the other > side, is not using regularly (in iPhone) more than 32m when executing. > That’s because you are not loading all image in memory, you paginate the > loading (and Mariano’s phd demonstrated that you usually does not use more > than 20% of what is inside your image, so most frequently you do not load > it completely at all). > > For DrGeo2 I needed to expand that memory to 64m, but it was still in the > reasonable numbers. > > Now, for distributing your application your image will be not equal to > your development image. You will strip things and reduce some others (there > is a shrink process that Pavel does in the Pharo-minimal image and time ago > I made some experiments and I ended with an usable 8m image running in > iPhone… I even got a 4m image but no morphic was present so it was using > ObjectiveCBridge to show some screens with functionality…) > Also, for production you will be removing sources and changes, so you do > not have to take those into account (even taking it, they are never loaded > into image, they are accessed when needed). > > So… I think a mobile final app of 20m - 50m (and take into account that a > 50m app will be really big, DrGeo2 was 35m) is perfectly reasonable. Is not > huge and most applications nowadays (even the stupid ones) occupies way > more. > > Now, that 5% idle is much-much more worrying that app size. And we already > have an even VM who does not consumes that (JB did it) It will be > integrated soon (JB needs to finish I don’t know exactly what). > > Esteban > > > On 25 Nov 2014, at 16:58, Esteban A. Maringolo <[email protected]> > wrote: > > Kilon, > > The comparison you're doing is wrong, you're comparing apples to oranges. > > To start with, I have Android KitKat where a clean Facebook app takes 33MB > (as per the latest release), Chrome 65MB, etc. You might be counting app > data as total size, but the data+cache part is variable and subject to each > device. > > 20+ Megs for mobile is HUGE, the only reason to use and download such apps > is if they are (or are perceived) as "indispensable", like social network, > mail or browsing. Games fall into a different category, the average size > for such apps take more space (but are also the first ones to be removed > when available storage starts to reach its limit). > > On the other hand you should compare Pharo apps/with other development > languages/IDEs/toolkits. Leaving aside GUI-less/file based tools (which are > smaller) Pharo shines during the development stage taking an order of > magnitude less than many of the IDEs out there. > But the produced artifacts, being indistinguishable from the development > image itself, takes the same size. > > Because it is "self contained" it uses only a few shared libraries or even > complete frameworks like JRE/.net. Pros and Cons of this approach. The > resource requirements of Pharo (and most Smalltalks) is linear as you add > more images, you can't leverage "common" code between them. > > My servers are "simple web apps" that take ~40MB of image + 100+ MB of > changes. All built from a clean Pharo image, with all caches flushed. For > me that is A LOT. Not to mention the constant 5% CPU idling. > > I can live with that because the benefits I get outweighs the cons > mentioned before, but saying that 40MB is not big for a program is not > true, and it's plainly false on mobile. > > And in my opinion, and take this as 100% personal taste/experience, but > being reckless about size/cpu requirements of the software you build leads > to bloatware. > > Regards! > > El Tue Nov 25 2014 at 5:07:26 AM, kilon alios <[email protected]> > escribió: > >> Ok here are the apps I use that loads of people also have in their phones >> that are more than 30 MBs >> >> 1) PDF Reader - 237MB >> 2) Facebook - 178 MB >> 3) Chrome - 148 MB >> 4) Respawnables (Game) 133 MB >> 5) Yahoo Mail - 126 MB >> 6) Firefox - 98 MB >> 7) Candy Crash Saga - 65 MB >> 8) G+ - 56 MB >> 9) Pet Rescue Saga - 53 MB >> 10) Google Search - 50MB >> 11) GMAIL - 43MB >> 12) Facebook Messenger - 35 MB >> 13) Google Maps - 32 MB >> 14) Twitter - 30 MB >> >> Also a +1.000.000 to Marcus about the fact that in a few years 4 GB Ram >> will be the standard for mobile platforms. >> >> Squeak is around 8Mbs but then I dont use it because it has all sort of >> issues on android. >> >> > >
