> On 25 Nov 2014, at 17:43, Clément Bera <[email protected]> wrote: > > > > 2014-11-25 17:24 GMT+01:00 Esteban Lorenzano <[email protected] > <mailto:[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 ?
I’m having 15% bigger images. I always assumed it was going to be like that because of the differences on header sizes… but I suppose the amount of ancient compact-non compact classes has something to do. Esteban > > but yet, memory management will be a lot more efficient so… :P > > Esteban > >> On 25 Nov 2014, at 17:22, Esteban Lorenzano <[email protected] >> <mailto:[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. >>> >> > >
