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