[ESS] Slow help culprit found!

[Martin Maechler]

On Sat, Oct 23, 2010 at 19:14, Seb <spluque at gmail.com> wrote:
> On Sat, 23 Oct 2010 18:21:50 +0200,
> Martin Maechler <maechler at stat.math.ethz.ch> wrote:
>
>> On Sat, Oct 23, 2010 at 12:35, Vitaie S. <spinuvit.list at gmail.com> wrote:
>>> spinuvit.list at gmail.com (Vitalie S.) writes:
>>>> The rationale of calling that function in `ess-find-help-file', is
>>>> somewhat elusive to me:
>
>>>> (ess-uniq-list (append (ess-g     et-help-files-list)
>>>>          (ess-get-help-aliases-list)                        (mapcar
>>>> 'list                                (ess-get-object-list
>>>>                       ess-current-process-name))))
>
>>>> It examines only *attached* packages, and thus, brings only
>>>> duplication (anything else?) of already comprehensive (but
>>>> efficient) `ess-get-object-list'.  Moreover ,
>>>> `ess-get-help-aliases-list' does not cache anything and rereads all
>>>> the RDS files each time one calls \C-c\C-v.
>
>>> Well, I see now (after removing ess-get-help-aliases-list) that there
>>> are topics in help not associated with any object.
>
>> well, of course, that's why this was a new *feature* (in ESS 5.9.1
>> which is a while old, why did nobody till now "complain" ?), really
>> quite important for consistent help page searching.
>
> Indeed, I had introduced this feature to make
> `ess-display-help-on-object' more comprehensive (everything with an
> \alias).  In my case (Debian sid AMD64, GNU Emacs 23.2.1
> (x86_64-pc-linux-gnu, GTK+ Version 2.20.1) of 2010-08-15 on barber,
> modified by Debian, ESS 5.11, and R 2.12.0), I've never experienced the
> delays that Vitalie describes, and this is the first time we hear this
> issue.
>
>
>>> Then, maybe `ess-get-help-aliases-list' can be changed to cache the
>>> output, and update only if search path was changed, akin to how
>>> `ess-get-object-list' works.
>
>> Yes, that's a good idea, ... patches are welcome ;-) .. or another ESS
>> core member has more time than I have currently ..
>
> I remember thinking about caching the output somehow, but since the
> impact of recomputing the completions was negligible, I kept things
> simple to begin with.  Time to reconsider.  I can look into this, but
> I'm afraid I won't be able to do so soon, so patches would be great!
>
Indeed.
As others have noted, it both depends on how fast your computer hardware is,
*and* on how many packages you have typically  in search().

I'm in the good camp: Fast hardware and not such a long search().
But nowadays, I imagine people attaching every package they
occasionally use and/or using
a huge globalenv...  all bad practices that are now punished by long
C-c C-v time  ;-) ;-)

... we nevertheless agree that  caching is a very reasonable wishlist
item here...
Martin