Re: XEmacs hash table representation (was XEmacs builds failing - gnus-spec.el)

[Ted Zlatanov <tzz@lifelogs.com>]

On Sun, 02 Jun 2013 09:22:34 -0700 Mike Kupfer <mike.kupfer@xemacs.org> wrote: 

MK> David Engster wrote:
>> It's not about the hash table metadata but about speed. Before Ted
>> rewrote the code, the registry used to do a conversion to/from an alist,
>> and I remember that writing/reading the registry this way was annoyingly
>> slow, at least on slow machines in combination with big registries (mine
>> has about 100.000 entries).

MK> Ah, okay.  Thanks for the clarification.

I've been wondering (in my free time) whether it would make sense to
provide an even faster binary backend for the registry file.

BSON looks pretty good.  Its C implementation is pretty simple.

https://github.com/casualjim/emacs.d/blob/master/elpa/mongo-20120826.14/bson.el
provides a pure ELisp implementation we could use if a C implementation
was not available (in older Emacsen/XEmacsen).

Right now all this is just idle wondering...

>> Of course, one could still do that specially for XEmacs. I guess all it
>> takes is to define a proper ':printer' slot for the registry
>> object. 

MK> For the sake of interoperability, I think that it'd be better to print
MK> the hash table for XEmacs (with print-readably set to t).  I did some
MK> (very) limited testing, and it looked like the printed representations
MK> of hash tables are compatible between Emacs and XEmacs.

They are not, unfortunately...  I forget the exact issues because this
was years ago but there were some annoying cases with the data, both
with the metadata and with the string encodings.

Ted