ron@mlfarm.uucp (Ronald Florence) (01/06/90)
Is there a way to speed up "describe-mode" in Gnu emacs modes that are
not pre-loaded, like gnus or calendar?
--
Ronald Florence ron@mlfarm.uu.net
{hsi,rayssd}!mlfarm!ronwilber@alice.UUCP (Bob Wilber) (01/08/90)
I looked at the C code for that a while back. The problem is that it's using a quadratic time algorithm for something that could be done in linear time (buffers are constantly being resized). However, to do this in linear time requires having a way to precompute how long each piece of text is going to be after all substitutions have been done (in a recursive fashion). It looks like a fair amount of work to speed it up. (Yes, it was describe-mode for calendar.el that inspired me to look into this. It took so long I thought my machine had gone down.) Bob Wilber wilber@homxb.att.com
tale@cs.rpi.edu (David C Lawrence) (01/09/90)
In article <10316@alice.UUCP> wilber@alice.UUCP (Bob Wilber) writes: > I looked at the C code for that a while back. The problem is that it's > using a quadratic time algorithm for something that could be done in linear > time (buffers are constantly being resized). However, to do this in linear > time requires having a way to precompute how long each piece of text is > going to be after all substitutions have been done (in a recursive fashion). > It looks like a fair amount of work to speed it up. Ok, now since you've described the underlying reason for it, I'll elaborate a little more. (Heck, I didn't even understand you the first time I read it and I supposedly know what you're talking about. :-) > (Yes, it was describe-mode for calendar.el that inspired me to look > into this. It took so long I thought my machine had gone down.) As of GNUS 3.12, one of the packages mentioned in the original keywords as exhibiting the problem, the speed has been greatly increased at the loss of some Ultimate Accuracy In Advertising. The problem with both older versions of GNUS and a slightly older version of calender that I just checked is that it they do a _lot_ of substitutions with substitute-command-keys when the doc string is being prepped for the *Help* buffer. There is indeed a little bit of manipulation which needs to go on to turn "\\[gnus-Subject-next-same-subject]" into "M-C-n". For the calendar-mode I just checked it has to do it thirty-four times in one very large documentation string. GNUS 3.12 has sped up the process by taking out the vast majority of \\[] substitutions intended for substitute-command-keys, leaving it only for those not bound by default and putting in the default bindings for the rest. If the bindings change then this loses, but for 99 44/100 % of the time it will be true enough. Dave -- (setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))
reingold@m.cs.uiuc.edu (01/10/90)
It's REALLY nasty to wait without some indication that the machine hasn't died! Since describe-mode doesn't give any messages, I've added such a message to calendar.el (all the latest stuff is in a.cs.uiuc.edu:pub/calendar and available by anonymous ftp). The message OUGHT to emmanate from describe-mode, since this is a general problem.
wilber@alice.UUCP (Bob Wilber) (01/10/90)
I wrote: >...[About how the C code for describe mode uses a slow algorithm.] Dave Lawrence (tale@cs.rpi.wdu) responded: >Ok, now since you've described the underlying reason for it, I'll >elaborate a little more. (Heck, I didn't even understand you the first >time I read it and I supposedly know what you're talking about. :-) > >As of GNUS 3.12, one of the packages mentioned in the original keywords >as exhibiting the problem, the speed has been greatly increased at the >loss of some Ultimate Accuracy In Advertising. >... >GNUS 3.12 has sped up the process by taking out the vast majority of \\[] >substitutions intended for substitute-command-keys, leaving it only for >those not bound by default and putting in the default bindings for the >rest. If the bindings change then this loses, but for 99 44/100 % of the >time it will be true enough. Under the circumstances this was a reasonable work-around, but it also illustrates that when a useful feature is implemented too inefficiently, people won't use it. The whole point of \\[] substitutions is to ensure that what comes up in the *Help* window conforms to reality, particularly in the 56/100 % of the cases where the bindings are non-standard. Of course this is most needed in modes that do a lot of key rebindings, which tend to have the most \\[] substitutions, which are therefore the modes where the slowness of describe-mode is most serious, and are therefore the modes where the programmer is most likely to forsake the use of \\[] altogether. Sigh. If I get *real* ambitious I might try fixing up describe mode myself, but I'm no Emacs mage and there's lots of stuff in the code I don't understand so well, so it's not going to happen anytime soon. Bob Wilber wilber@homxb.att.com