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/Debugging
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