[Pharo-project] Are the any Fuel file analysis tools/techniques?
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?
+1 I'd be very interested in that sort of thing. On 02.11.2012, at 19:08, Yanni Chiu <yanni@rogers.com> 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?
[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 <yanni@rogers.com> 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?
Hi guys. Indeed, this is something we wanted since a long time and it has already been discussed: http://code.google.com/p/fuel/issues/detail?id=163 Unfortunately, nobody had time to do it. What we do have is written here: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/D... but the visualization that does not work well if the graph is large. If your object graphs you usually serializer are around a known range of size, you can check after the serialization if that was the case, and if it was not, then debug it. Something you can do is to put a halt in FLSerialization >> #run just after doing the "self analysisStep.". At that point, you can inspect the instVar 'clusters'. You can see which clusters you have and each cluster understand #objects which answers all the list of objects associated to that cluster. If a cluster corresponds to a particular class you can also ask #theClass. But this only works for the serialization, not for the materialization. Cheers, On Sat, Nov 3, 2012 at 10:54 AM, Max Leske <maxleske@gmail.com> wrote:
+1 I'd be very interested in that sort of thing.
On 02.11.2012, at 19:08, Yanni Chiu <yanni@rogers.com> 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?
-- Mariano http://marianopeck.wordpress.com
On 04/11/12 6:43 AM, Mariano Martinez Peck wrote:
But this only works for the serialization, not for the materialization.
FLMaterializer>>materializeFromFileNamed: aFilename ^ (self materializationFromFileNamed: aFilename) root I've been using #materializeFromFileNamed: in my code, but I just happened to pick #materializationFromFileNamed: while debugging another problem, a moment ago. When I inspect the resulting FLMaterialization object, I can see the clusters - which is exacting what I was looking for a few days ago. By scanning the clusters, it should have been easy to figure out what objects should never have been serialized (e.g. WASession). Which was a critical clue to figure out where to look for where the extra objects were coming from.
On Mon, Nov 5, 2012 at 5:24 AM, Yanni Chiu <yanni@rogers.com> wrote:
On 04/11/12 6:43 AM, Mariano Martinez Peck wrote:
But this only works for the serialization, not for the materialization.
FLMaterializer>>**materializeFromFileNamed: aFilename ^ (self materializationFromFileNamed: aFilename) root
I've been using #materializeFromFileNamed: in my code, but I just happened to pick #materializationFromFileNamed: while debugging another problem, a moment ago.
When I inspect the resulting FLMaterialization object, I can see the clusters - which is exacting what I was looking for a few days ago. By scanning the clusters, it should have been easy to figure out what objects should never have been serialized (e.g. WASession). Which was a critical clue to figure out where to look for where the extra objects were coming from.
Yes, you are totally right. What I ment is that at this point (to be able to inspect instVar 'clusters') the materialization has already happened, I mean, the graph is already materialized and in memory. That's why I was suggesting that maybe it was better to get this info before the serialization itself. But anyway, yes, this will also be helpful. -- Mariano http://marianopeck.wordpress.com
participants (3)
-
Mariano Martinez Peck -
Max Leske -
Yanni Chiu