Re: [elephant-devel] Untangling "serialize"

2007-12-28 Thread Sean Ross
AFAIK this goes for SBCL, CMUCL, Lispworks and ACL. On 12/27/07, Evrim Ulu <[EMAIL PROTECTED]> wrote: > SBCL generic function dispatcher is faster than function + typecase. > > evrim. > ___ > elephant-devel site list > elephant-devel@common-lisp.net > ht

Re: [elephant-devel] Untangling "serialize"

2007-12-27 Thread Evrim Ulu
[EMAIL PROTECTED] wrote: 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 vers

Re: [elephant-devel] Untangling "serialize"

2007-12-26 Thread midfield
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. proba

Re: [elephant-devel] Untangling "serialize"

2007-12-26 Thread Ian Eslick
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

[elephant-devel] Untangling "serialize"

2007-12-26 Thread Leslie P. Polzer
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://bl