Miles Bader raised some valid points.  Attached are updated versions of
xcache.[ch].  Some comments:

- Changed the bracing, line width, and some other formatting to be more
  GNU'ish.  Please let me know if there are other formatting issues lacking.

- The keys were being xmalloc'ed (unnecessarily) and then leaked.  Instead
  each of the wrapper functions now has a static buffer (of a #define'able
  size) to store the transient keys.  

- I decided to stay w/ the memory copying for the keys (instead of writing
  custom compare functions for each query type and then storing the cached
  data's type in the _xcache_record) because it is a cheap, local
  operation.  A typical emacs startup session might take on the order of
  magnitude of 900 X requests which incurs net lag, but 900 calls to a
  wrapper function that get executed locally are completely negligible.
  Custom compare functions would introduce a level of complexity that I
  think is unwarranted.

Using static buffers seems to speed up the whole thing even more!  With my
.emacs it's down to 30s and without (emacs -q) it's down to 28s.  

I'd be interested to hear from anyone about:
1) Have you tested this?  What sort of speed improvements do you see?
2) Am I doing anything else very stupidly (such as leaking every call :))?
3) Do you have any ideas on caching XFontStruct's?  Specifically, the
   XExtData* list has private_data members whose size is unknown (as far as
   I can see).
4) Adding an option to configure.in to enable a (default=off) switch for
   USE_XCACHE.  I don't feel like learning autoconf for this one thing.
5) Miles mentioned someone else took a crack at this at some point.  I'd be
   very interested to hear about this experience.  There is something 
   morally wrong about caching this info, but I'm willing to be a little
   naughty to cut out the ridiculous lag delays in remote X emacsen... 
6) Any other thoughts on this.

Cheers,
-- 
  Ami Fischman
  usenet@fischman.org