i was trying to be smarter than the compiler -- i don't remember if PCL can do runtime profiling directed dispatch tables -- i attempted to generate the optimal dispatch table "by hand." as moon would say, given a sufficiently smart compiler.....the generic function version would be better. probably ACL and Lispworks are ahead in this way than the PCL-based lisps.
b On 12/27/07, Ian Eslick <[EMAIL PROTECTED]> wrote: > 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@common-lisp.net > > http://common-lisp.net/mailman/listinfo/elephant-devel > > _______________________________________________ > elephant-devel site list > elephant-devel@common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
