[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Converting CC Mode's obarrays to hash tables. [Was: new `obarray` type]
From: |
Alan Mackenzie |
Subject: |
Converting CC Mode's obarrays to hash tables. [Was: new `obarray` type] |
Date: |
Sun, 23 Jul 2017 14:03:10 +0000 |
User-agent: |
Mutt/1.7.2 (2016-11-26) |
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).
- Converting CC Mode's obarrays to hash tables. [Was: new `obarray` type],
Alan Mackenzie <=