[elephant-devel] Untangling "serialize"

Ian Eslick eslick at csail.mit.edu
Wed Dec 26 19:42:19 UTC 2007


Yes and no.  I think the tradeoffs are not totally obvious.

The serializer/deserializer was written by the original authors for  
performance reasons.  Arrays, hashtables and lists in particular  
require lots of recursive calls to %serialize/%deserialize.  That can  
translate into many generic function dispatches in an inner loop.   
It's not clear how large the performance impact would be though; I  
haven't been motivated enough yet to test the change under enough  
different usage models to be sure it doesn't have a deleterious effect  
on any one.

You'd also have to push some of the shared let bindings into global  
variables or generic function arguments such as the serializer-hash  
and id counter.

I did something similar to this with the migrate function  
(migrate.lisp), but there the performance didn't matter.  I'm not sure  
that code is any cleaner for being broken up than it would be if I had  
put it all in one function with typecase lines to clearly delineate  
type-specific functionality.

It would be interesting to see a performance comparison between the  
optimized and general approach and whether the other formulation reads  
better.

Ian


On Dec 26, 2007, at 11:39 AM, Leslie P. Polzer wrote:

>
> It's not really of immediate concern for me, but wouldn't it
> probably make sense to split the "serialize" function into
> a generic function and a bunch of methods? It's currently
> a giant typecase mudball.
>
> It would in any case be more extensible this way.
>
>  Leslie
>
>
> -- 
> My personal blog: http://blog.viridian-project.de/
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel




More information about the elephant-devel mailing list