RE: (describe-function 'self-insert-command) takes too long

[Drew Adams]

    >     There is no noticeable delay even for commands bound to a few
    >     dozen keys, but self-insert-command is bound to zillions of
    >     them. It is essentially a special case that needs to be treated
    >     as such, or else, as I say, the list of keys should be computed
    >     only up to some limit.
    >
    > Some more info on this, FYI: In my build, on my machine,
    > measuring using this (thanks, Lennart) gives 0.701 seconds (IIUC):

    So what is the problem?  How often do you ask that same question?

What question?

    Even if it took 2-3 seconds, I don't see the importance of fixing this.

    > Doing the same thing for command `forward-char' gives 0.05 seconds:
    >
    > => (17713 7521 950000) (17713 7521 960000)
    >
    > That's an order of magnitude difference (factor of 14). And
    > 0.7 seconds renders this essentially non-interactive, especially
    > when combined with the possible overhead of other processing
    > (e.g. calling describe-function from another command).

    Huh?  Who would do that (more than once)?

Who would do what more than once?

    If you have code which (senselessly) calls describe-function for
    self-insert-command, maybe you could do the clever part...

I have code that provides a browser of keys and their bindings. As a side
feature, you can get help about a binding on the fly, during completion
(e.g. before using it). You C-click (or C-RET) a completion candidate to see
its help. For keys bound to self-insert-command, the help appears only after
a second or two delay. For all other keys, the help display is
instantaneous.

describe-function should be a quick command - quick enough to click a key
bound to it and see the help result immediately. A one- or two-second delay
is not very interactive. Command self-insert-command is the only exception,
which causes describe-function to be slow.

Looking up bindings is only a tiny part of what describe-function does. And
all of the bindings that it looks up for self-insert-command are anyway
thrown away - the time spent doing that takes away from interactivity
(responsiveness), and it is totally wasted time - useless. It's not as if it
were an unavoidable cost of doing something useful.

The only thing "senseless" here is the fact that describe-function
calculates all of the ~5000 bindings for self-insert-command, and then
throws them all away. There is no reason for that. The code can be rewritten
to only gather bindings up to a certain limit.

    > Besides, all of that processing time is simply wasted,

    My computer spends more time in the idle loop than anything else,
    no matter how fast I throw commands at it.
    I think I can spare 0.7 seconds.

Irrelevant. When you click a button (or whatever), you don't expect its
dialog box (or whatever) to be displayed after a delay of a couple of
seconds; you expect it to appear immediately.

Interactivity requires a faster response than that, unless the contrary is
unavoidable. In this case, it is entirely avoidable. There is no reason for
a user to wait that long, since the time is spent uselessly looking up
bindings that are just thrown away (not displayed).

    > since the calculated
    > key bindings are just thrown away, replaced by the "many ordinary text
    > characters" help. The code should be smarter than that.

    I don't see why!

And I don't see why not (nor why you are so sensitive about this,
apparently). Why compute (look up) 5000 bindings and then throw them away?
Why not compute bindings only up to a max of, say, 100 (or 200 or 400, but
certainly not 5000)?

    And anything smarter could mean that it would have to know something
    in advance - and how can it do that?

What does it have to know? It can just stop calculating when it has already
found 100 bindings. Put the length filter inside the loop, instead of
outside it - filter promotion; that's all. Tell me, if I'm misunderstanding
(and no need to shout). AFAICT, this shouldn't be a big deal.

    You cannot just modify describe-function to always say "many ordinary
    chars"; for self-insert-command, as the user may actually rebind all
    chars to something else!

So use a limit. Today, a limit is used only after determining all of the
bindings; it is used just to throw stuff away. Why not be lazier and use the
limit to only look up that many bindings, max, in the first place? IOW,
don't create the unneeded list of 5000 bindings, just to toss it away.

    IMO, there is no problem here.

I see no reason why this code can't be quick, reactive. What is gained by
keeping the current calculation of all bindings? What is lost by not looking
up the extra bindings that will only be thrown away?