Figuring out why my image balloons to 500+ megs and is not shrinking despite new compactor was a nice one + fact that it took 2 minutes to start.
Fixed yesterday with the help of Clement and Pavel. First, there was a massive leak of memory from the devtools. https://gist.github.com/philippeback/39c63bb5aa26b79098511cdfea4fea7e fixed it (got the image back to 130 megs, which was ok given the amount of loaded code). Then looking at the startup times to find out the culprit: https://gist.github.com/philippeback/9b6645c62b4cda7c0d4559880fbbe40f Save/Stop/Start and then inspect LOG11. This gaves us entry related to FT2Settings talking the lion share of the delay. Looks like this was because it was refreshing fonts at startup. On my Windows box is was 650 font entries. On Ben's Linux this was 1500+. Ben advised to change this FTHandle>>pvtDestroyHandle, try commenting out the last statement... FT2Handle allSubInstancesDo: [ :each | (handleToRelease = each handle) ifTrue: [ each beNull ] ] This indeed made things faster even with the setting. No proof that will be not leading to more trouble b/c this code supports the workaround for FT2Handle duplicates (that FT2 bug alone deserves a cake too by itself). So, things are back to normal now in that image and nothing had to do with my own code. Thx again for the help. And compactor works wonderfully indeed. Note that current figures in the VM Stats are completely bogus at places and need to be rewritten/recomputed since we are using Spur and things are not the way they used to be. I took plenty of notes from what Clement told me. Hope to integrate that into the MemoryMonitor at one point. Phil
