Converting CC Mode's obarrays to hash tables. [Was: new `obarray` type]

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Wed, Mar 15, 2017 at 13:25:08 -0400, Stefan Monnier wrote:
> > There are currently four uses of (make-vector LENGTH 0) in CC Mode, at
> > least one of which, possibly two, genuinely deal with Lisp symbols.
> > Converting those to hash-tables would probably be a net loss, though
> > converting the ones which just use obarrays as a string look-up would
> > surely gain.

> I just tried such a conversion on all 4 uses.

> The result isn't that bad, but indeed contrary to the EIEIO case, I get
> a slight slow down (somewhat lost in the measurement noise, but still
> a disappointment for me).  The culprit seems to be the use of cl-structs
> instead of symbols in c-lang-constants (I can recover some of the speed
> by adding (:type vector) (:named nil) to the defstruct definition).

I've just converted c-found-types to use a hash table.  The result was a
slight, but measurable and worthwhile, speed increase, of between 1% and
2%.

As for c-keywords-obarray (an obarray which has C (etc.) keywords as its
symbols, whose property lists contain the various keyword categories the
keywords belong to) - what is the benefit of holding collections of
symbols in hash tables rather than obarrays?  If this makes a program
faster, it suggests that the obarray implementation could be improved to
match the speed of the hash table implementation.  Why don't we store
the main Emacs obarray in a hash table, if this will increase speed?

> In case you're interested in extracting the rest, find the patch below
> (which was pretty thoroughly *un*tested),

Thanks, I read it.

>         Stefan

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).