and btw… spur format will consume more memory. 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] >> <mailto:[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] >> <mailto:[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. >> >
