Hi Tim,

On Sun, Aug 14, 2016 at 11:44 AM, tim Rowledge <tim@rowledge.org> wrote:


> On 14-08-2016, at 4:03 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
>
>
> Hi Tim,
>
>> On Aug 11, 2016, at 11:14 AM, tim Rowledge <tim@rowledge.org> wrote:
> [snip]
>
>> The image is frikkin’ huge. How on earth do we have 22Mb of ByteArray/BitMap/ByteString around? And it looks like we are keeping a very large amount of MC stuff; 13018 instances of MCVersionInfo/MCVersionName/DateAndTime/Date/Time/UUID. Is that smart? Simply flushing the cached ancestry from the MC browser gets rid of 60% of them and appears to save 3Mb. Except the damn saved image afterwards is exactly the same size! Sigh.

Build a VMMaker image with image/buildspurtrunkvmmaker.sh and you can now use Spur32BitPreen to rewrite the image to be more compact.  We can use this as part of the release process until Clément and I have fixed Spur compaction.  e.g.

Spur32BitPreen new preenImage: '../oscogvm/image/trunk50'
Looking for module  ... loaded...computing accessor depths...done
Looking for module  ... loaded...computing accessor depths...done::::.............................................done.
old heap size: 41,897,472 initial new heap size: 26,818,472
change: -35.99%
final new heap size: 26,818,472 change: -35.99%

Done!
 
HTH
_,,,^..^,,,_
best, Eliot