[Vm-dev] Re: [Pharo-dev] What is the limit

Tue Nov 25 18:42:17 UTC 2014

On Tue, Nov 25, 2014 at 8:43 AM, Clément Bera <bera.clement at gmail.com>
wrote:

>
>
> 2014-11-25 17:24 GMT+01:00 Esteban Lorenzano <estebanlm at gmail.com>:
>
>> and btw… spur format will consume more memory.
>>
>
> Why ?
>

32-bit Spur grows the image by about 15% over 32-bit V3.  This is because
- all objects have a 64-bit header, whereas compact headers in V3 mean that
small Arrays and CompiledMethods have a 32-bit header.
- all objects are padded to a 64-bit boundary whereas in V3 objects are
padded to a 32-bit boundary.

> If I remember correctly  the first Squeak image generated was 3% smaller.
> How bigger is the spur Pharo image compared to the regular image ?
>

No, that was my clerical error that I stupidly wrote up in my first blog
post.  I corrected the pst a while back.  +15% is the consistent result
nowadays.

Note that 64-bit Spur grows by about another 25%, giving about a 44%
increase over V3.

but yet, memory management will be a lot more efficient so… :P
>>
>> Esteban
>>
>> On 25 Nov 2014, at 17:22, Esteban Lorenzano <estebanlm at gmail.com> 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 <emaringolo at gmail.com>
>> 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 <kilon.alios at gmail.com>
>> 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.
>>>
>>>
>>
>>
>

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141125/8ba15591/attachment-0001.htm