help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] the test test - a more detailed analysis of image c


From: Paolo Bonzini
Subject: Re: [Help-smalltalk] the test test - a more detailed analysis of image contents
Date: Sat, 18 Jul 2009 10:55:24 +0200
User-agent: Thunderbird 2.0.0.22 (Macintosh/20090605)

> ot.im is the preloaded image, my OnlineTester package, depending
> on Iliad. The other images were saved via 
>   gst-remote --eval="ObjectMemory snapshot"
> after finishing the test session.

Can you place them somewhere I can download them?  They are interesting.

>   [ ObjectDumper dump: usage to: s ] ensure: [ s close ]

Nice :-)

> Swazoo and Socket objects don't seem to be out of range, either,
> considering the Process count.
>   Process: 5 -> 258

A bit too many?  Maybe something is holding onto them.

> Iliad object counts seem to be a bit high, except for Session,
> and they stay that way, even after a garbage collection.

Then we have to see what's the root for them.  Maybe some Process?

>     Iliad.CurrentContext
>     Iliad.ResponseNotification
>     Notification
>     SystemExceptions.ProcessBeingTerminated

These are notifications and are not a problem.

>   HomedAssociation: 3 -> 548
>     note to self: look up what that is.
>     map temporary stuff to nil

Related to weak collections and finalizations.  Probably sockets.

>   Association: 524 -> 178658
>   Dictionary: 10 -> 108373
>     the former are stored in the latter and are almost
>     completely iliad stuff

100000 dictionaries are a bit too many.  And anyway changing them to
LookupTables would save 178658 * 12 bytes for the associations.

>   OrderedCollection: 60 -> 109188
>     let's count sizes again
>       Bag(0:70960 32:3 1:27178 97:1 3:5211 2:160 64:1 
>         7:85 4:57 6:57 5:3 288:1 135:1 14:1117 8:199 
>         13:30 9:28 11:4052 10:31 43:2 12:3 576:1 28:1 
>         17:1 92:1 18:1 3246:1 20:1 2304:1 1152:1 )
>       ooh ... 70k empty OC's 

70000 * approx 40 bytes here to save too if you can use lazy
initialization...

>       the 5k 3-element OC's are either the mime-type collection
>         ('application/json' ' text/javascript' ' */*' )

Probably some result of parsing Accept fields?  For many
OrderedCollections, adding asArray strategically would save memory at
the cost of creating more garbage.

Summary: there's definitely something to optimize in code that creates
too many collections.

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]