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.
Sorry about this. This is due to the immaturity (brokenness) of the Spur compactor. There is a reasonable solution for the release process, which is to modify the 32- to 64-bit bootstrap to allow the VM simulator to clone a 32-bit image having squeezed the free space out of it. I'll try and get in this asap. By year end I hope that Clément and I will have rewritten the compactor to eliminate this embarrassingly bad behaviour.
Argh, yes, I remember you mentioning this in the past.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one? -- Tom Cargin