RE: Q on performance with 10000 faces

[Drew Adams]

Hi Kim,

    > A more complete version of the code is here, in case that helps:
    > http://www.emacswiki.org/cgi-bin/wiki/palette.el.

    Note: It depends on hexrgb.el

Yes.

    (although is says no dependencies).

You mean the "Features that might be required by this library:" comment in
the file header? Yes, I forgot to byte-compile the file and load the
byte-compiled version before I saved it, so that automatically generated
comment didn't get updated correctly. (There is an explicit (require
'hexrgb), at least.)

FYI - The way the automatic file-dependency header works is that if a
byte-compiled (`*.elc') version of a library is available it is loaded, in
preference to the source library - this is the standard behavior of
`load-library'. The list of required features then reflects the dependencies
indicated in the byte-compiled file, not the source file. If the
byte-compiled file is out-of-date, so will be the file header list of
possible dependencies. The code for this is here, BTW:
http://www.emacswiki.org/cgi-bin/wiki/lib-requires.el (and
http://www.emacswiki.org/cgi-bin/wiki/header2.el). Suggestions welcome.

    Anyway, I tried your code, and I don't see any apparent slowdown, once
    the palette frame is shown (but that takes a few seconds).

Yes, it takes about 4 sec on my machine to create the palette. That's not a
real problem (for me).

    Repeated cursor movement doesn't happen instantly with the default
    settings, but with (setq redisplay-dont-pause t), key response is ok.

Use of that variable is not clear to me, even after reading the doc. I was
thinking that non-nil would slow things down when there is pending input, by
allowing redisplay instead of inhibiting it. How does non-nil improve
response here? Where would you suggest binding it to non-nil - in each of
the interactive functions (in the palette code) or just some in particular?
I'm confused about this variable. Usage guidelines welcome.

Anyway, I tried setting redisplay-dont-pause to non-nil globally, just to
see what you mean, and I don't notice any improvement. I don't doubt you,
but I didn't notice a change, myself.

    How significant is the slowdown you see?

As I mentioned before, with various hooks and such that I have running in my
setup, M-x takes a couple of seconds to give me the prompt (once the palette
has been displayed). However, response for cursor movement, mouse clicking
etc. is not a problem. It's mainly minibuffer response that is slow.

That's the fault of other libraries I use, but the point is that I don't see
any slowdown unless I run the palette code. IOW, it slows things down enough
to be quite annoying, because I already have a lot going on. The other stuff
going on I never notice, in terms of response, but in combination with the
palette code, it's quite noticeable. That suggests to me that the palette
code is slowing things down, and that slowdown is just not very noticeable
with emacs -Q + palette.

In any case, even without any special attempt at optimization, the palette
seems quite usable. I'm sure there is room for optimization of my code, even
apart from any possible improvement in Emacs' display of faces.

[The problem I'm having now with the library is finding a font to use - each
user's font selection is different. I try to pick up a small font (size 5),
using a priority list of fonts and ending with whatever size-5 font can be
found. But I'm not convinced that is a good solution. All I need is a small
font, preferably fixed-width - and I use only two characters (space and
`e').]

Thanks for having taken a look.