[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ess-help
Subject:    Re: [ESS] Tips for preventing slowing down?
From:       Marc Schwartz via ESS-help <ess-help () r-project ! org>
Date:       2019-11-13 21:04:56
Message-ID: B451BC01-8410-4383-86EC-5CDBD741A4EC () me ! com
[Download RAW message or body]

Hi,

To throw out one, potentially arcane possibility, in addition to Martin's c=
omment below.

Check your .emacs file for the following entry:

  '(global-linum-mode t)

This is to display line numbers in the buffer frame, in addition to the mod=
e line, if used.

With Emacs 26.x, this should not be used, rather you should use:

  '(global-display-line-numbers-mode t)

My recollection is that when I made the switch to Emacs 26 last year, I sti=
ll had the former entry in my .emacs file.

I had noted the progression of a slowdown with large buffers, both in terms=
 of general scrolling, as well as during the Sweave related processing of a=
 large .Rnw file.

The latter entry is part of Emacs 26.x, whereas the former goes back to cir=
ca Emacs 22/23, I believe. The position of the line numbers in the buffer f=
rame is also different now, than with the prior linum mode.

Through a lot of trial and error, I found this to be the etiology of my slo=
w scrolling behavior and I am back to a speedy Emacs, even with files of 10=
s of thousands of lines. There was some conflict between the older linum mo=
de and Emacs 26.x.

Regards,

Marc Schwartz


> On Nov 13, 2019, at 3:14 PM, Martin Maechler via ESS-help <ess-help@r-pro=
ject.org> wrote:
> =

> Thanks a lot Bill.
> =

> I've observed the same... and so have others,  often very experienced R u=
sers.
> =

> One thing some of us found was that  'flymake' was very harmful in
> these situations,  so we have turned it off (or tried to ...)
> completely.
> But I have to acknowledge that it does not solve the problem in some case=
s:
> https://github.com/emacs-ess/ESS/issues/490#issuecomment-538682487
> -->    (setq ess-use-flymake nil)
> =

> Relatedly maybe (or not), I tend to have a suspicion that the "newish"
> ESS behavior of  "taking over" your default directory, and adapting
> behavior of  emacs *shell*   is also harmful, notably when that
> *shell* buffer also becomes 10000s of lines long.
> =

> On Wed, Nov 13, 2019 at 5:28 PM William Denton via ESS-help
> <ess-help@r-project.org> wrote:
>> =

>> I'm finding that large ESS buffers, where I've been running a lot of com=
mands,
>> really slow down Emacs.  I use R a lot in Org, so when I'm working on so=
mething
>> I'm running little R code blocks over and over, and then regenerating th=
e entire
>> document by running all the commands.
>> =

>> After a while, the ESS buffer gets large, and things get slow.  I mean r=
eally
>> slow, to where keystrokes get missed because of the lag.  I thought it m=
ight be
>> swiper and ivy, so I disabled them, but the problem still happens.  Runn=
ing R
>> at the command line doesn't lead to slowdown.
>> =

>> I ran the profiler while I spent fifteen minutes or so in Org and ESS ru=
nning R
>> commands, and the highlights are this:
>> =

>> - timer-event-handler                                           15189  3=
4%
>>    cancel-timer-internal                                         8411  1=
9%
>> =

>> - command-execute                                               14995  3=
4%
>>  - call-interactively                                           14995  3=
4%
>>   - funcall-interactively                                        8411  1=
9%
>>    + org-export-dispatch                                         3822   =
8%
>>    + org-ctrl-c-ctrl-c                                           3702   =
8%
>>   - byte-code                                                    6583  1=
5%
>>    + read-extended-command                                       6583  1=
5%
>> =

>> - ...                                                           12560  2=
8%
>>    Automatic GC                                                 12552  2=
8%
>> =

>> I don't know what to make of this, though, or if there's anything there =
that
>> might indicate what I should do.  Do others have the same experience tha=
t large
>> ESS buffers slow down Emacs?  Is there any advice about what might help =
stop
>> that?
>> =

>> Thanks,
>> =

>> Bill

______________________________________________
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help
[prev in list] [next in list] [prev in thread] [next in thread]