Hi,
The etoys image size has grown to over 30MB now. How can I generate a report on the top memory hogs by categories or classes (and their instances, of course)? How do I make sure that memory hogs are indeed really needed in the base image and cannot be parceled into projects.
TIA .. Subbu
On 11.06.2009, at 08:16, K. K. Subramaniam wrote:
Hi,
The etoys image size has grown to over 30MB now. How can I generate a report on the top memory hogs by categories or classes (and their instances, of course)? How do I make sure that memory hogs are indeed really needed in the base image and cannot be parceled into projects.
SpaceTally new printSpaceAnalysis: 1 on: 'space.txt'
- Bert -
On Thursday 11 Jun 2009 3:07:51 pm Bert Freudenberg wrote:
On 11.06.2009, at 08:16, K. K. Subramaniam wrote:
Hi,
The etoys image size has grown to over 30MB now. How can I generate a report on the top memory hogs by categories or classes (and their instances, of course)? How do I make sure that memory hogs are indeed really needed in the base image and cannot be parceled into projects.
SpaceTally new printSpaceAnalysis: 1 on: 'space.txt'
This shows that the top three hoggers are ByteString, Array and CompiledMethod. Most of the space is in CompiledMethod (I suppose most of the objects in the other two are influenced by this count). I got a breakup by size. Most of the space is occupied by very small methods (20..40 bytes). It is like death through thousand cuts :-). I can trace senderless methods and then onto unused classes manually. I also saw methods for minor and major shrink but they appear obsolete.
Is there an automated way to track unused stuff in an image on an ongoing basis? How do the master image builders keep an image trim?
Subbu
On 04.07.2009, at 11:54, K. K. Subramaniam wrote:
On Thursday 11 Jun 2009 3:07:51 pm Bert Freudenberg wrote:
On 11.06.2009, at 08:16, K. K. Subramaniam wrote:
Hi,
The etoys image size has grown to over 30MB now. How can I generate a report on the top memory hogs by categories or classes (and their instances, of course)? How do I make sure that memory hogs are indeed really needed in the base image and cannot be parceled into projects.
SpaceTally new printSpaceAnalysis: 1 on: 'space.txt'
This shows that the top three hoggers are ByteString, Array and CompiledMethod. Most of the space is in CompiledMethod (I suppose most of the objects in the other two are influenced by this count). I got a breakup by size. Most of the space is occupied by very small methods (20..40 bytes). It is like death through thousand cuts :-). I can trace senderless methods and then onto unused classes manually. I also saw methods for minor and major shrink but they appear obsolete.
Is there an automated way to track unused stuff in an image on an ongoing basis?
Don't think so.
How do the master image builders keep an image trim?
We do not use out work images to build a release but one "master image" (the dev image) and only load updates, then save it.
- Bert -
On Jun 10, 2009, at 11:16 PM, K. K. Subramaniam wrote:
The etoys image size has grown to over 30MB now. How can I generate a report on the top memory hogs by categories or classes (and their instances, of course)?
Look in class SpaceTally for a number of methods you can call to obtain this kind of analysis. One good choice is "SpaceTally new printSpaceAnalysis: 1 on: 'STSpace.text'".
-- Scott
etoys-dev@lists.squeakfoundation.org