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 <[email protected]> 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? > > > > > > > -- Mariano http://marianopeck.wordpress.com
