[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Documentation for "Clone Buffers" (corrected version)

From: Eli Zaretskii
Subject: Re: Documentation for "Clone Buffers" (corrected version)
Date: 22 Mar 2004 08:40:40 +0200

> From: Richard Stallman <address@hidden>
> Date: Mon, 22 Mar 2004 00:24:19 -0500
>     If implemented naively, that could be prohibitively slow, I think.  To
>     get a feeling how slow, try "info --apropos=SOMETHING" with the
>     stand-alone Info reader.
> They are not comparable.  That searches all manuals.  I am talking about
> searching a specified list of manuals.

It was a long time since I did those experiments, but I think I saw
poor performance even when only a few manuals were visible.  I will
try to experiment again.

> However, this comparison might be valid in the case of commands,
> because many manuals might define at least one command.  So in the
> case of commands we might want to put the command names into the
> special node of `dir'.

Doesn't this require changes in install-info, and thus has one of the
2 disadvantages you mentioned in your other mail?  (FWIW, I don't
think that changes in install-info or in the language are such a
significant disadvantage.)

> I think it would be a mistake to use a database that does not consist
> of straightforward text.  The speed of searching text for a string is
> so fast that there is no point in optimizing it.

Perhaps in Emacs it is, but IIRC that's not true for the stand-alone
reader, whose search algorithm is very simple and thus inefficient
for large chunks of text.

But I agree that we should try plain text and see what is the actual
speed before we decide to do something more complex.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]