[cc: Seaside and Pier mailing lists]
Postmortem, no polished code...
First tried the "space" analysis tool from the "status" application tool
of Seaside. It showed only objects with more than 100 instances, which
did not give much useful info. with my data set. I suppose I could have
changed the threshold.
Second try: since the exported structure is a Pier kernel, I created a
subclass of PRVisitor that visited each structure and its children,
printing each structure on the Transcript. It did not find any extra
objects in the deserialized kernel.
Third try: create another PRVisitor that visited the kernel using
#instVarAt: and #at: for variable classes. Again, it did not locate the
extra objects.
Fourth try: somehow inspired to examine #fuelAfterMaterialization.
Placed a halt where it was called. Tried to filter the calls to only the
objects where my code had specialize #fuelAfterMaterialization. While
trying to get this filtering right, I noticed that the materialized
object was a WAUserConfiguration instance. Using explore pointers,
eventually found WASession instances and whatnot, being de-serialized.
Using Smalltalk>>garbageCollect and regenerating a test Pier kernel,
eventually led to a single WASession instance to trace. It led to a
PRComponent holding its prototypeInstance object, which then held a
non-nil PRContext.
The solution, add:
PRWidget class>>fuelIgnoredInstanceVariableNames
^#(context)
The prototypeInstance construct was introduce by Magritte3/Pier3. I
didn't have this issue before moving the Pier3. Clearly, I need better
test cases.
On 03/11/12 5:54 AM, Max Leske wrote:
+1 I'd be very interested in that sort of thing.
On 02.11.2012, at 19:08, Yanni Chiu
<[email protected]> wrote:
This scenario has happened a few times... Stuff is serialized and
de-serialized (to/from files) without problem. Code changes are
made. At some later date, I notice that the Fuel file is orders of
magnitude bigger than it used to be.
I usually manually de-serialize, and navigate the structures until
I find the cause of the bloating.
Is there some package or code snippets that can quickly summarize
the object classes and sizes in a serialized file, or from its
in-memory de-serialized form?
