emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [Orgmode] Re: Org file rendering/manipulation too slow


From: Nick Dokos
Subject: Re: [Orgmode] Re: Org file rendering/manipulation too slow
Date: Sun, 05 Sep 2010 22:07:22 -0400

Marcelo de Moraes Serpa <address@hidden> wrote:

> Hi Nick,
> 
> The output of elp-results is attached. I have opened a big org file I
> have, and navigated through the items a bit.
> 
> Thanks,
> 
> Marcelo.
> 
> On Mon, Aug 30, 2010 at 9:31 PM, Nick Dokos <address@hidden> wrote:
> > Marcelo de Moraes Serpa <address@hidden> wrote:
> >
> >> Yeah, thanks. It is really a shame that emacs will run orgmode this
> >> slow on OSX. OSX is now my platform of choice, and emacs my editor of
> >> choice. I keep a big reference org file with tons of tons of notes,
> >> but, even with the settings you suggested (thanks for that!) it is
> >> still very slow. I'm considering switching my notes to evernote,
> >> although I would really like to just stay with emacs+orgmode, but it's
> >> just too slow as of now :(
> >>
> >
> > Please take a profile: Just do
> >
> >       M-x elp-instrument-package <RET> org <RET>
> >
> > then run the slow command, then M-x elp-results and post the output to
> > the list. It might not be enough to solve your problem but it would at
> > least provide *some* information.
> >
> > Thanks,
> > Nick
> >

OK - thanks for doing that. Given the stats:

,----
| org-cycle                                                     3           
0.050032      0.0166773333
| org-cycle-internal-local                                      3           
0.04951       0.0165033333
| org-optimize-window-after-visibility-change                   2           
0.0380670000  0.0190335000
| ...
`----

it seems clear that org-mode is not the culprit and, at 0.05s, any
improvements made there are going to be completely swamped by the real
time sink (maybe the display code if I understand things correctly.)
Also, presumably you are not complaining about the 50ms delay: that
would be almost unnoticeable. How long does it take for emacs to show
you the file?

Some questions:

How much memory do you have on your system? How much memory does emacs
consume? Is your disk active when emacs is taking forever?

On linux, I get the first with

         sed 1q /proc/meminfo

and the second with

         ps awlx | grep emacs

and look at the RSS field (field 8 in the output); e.g.

,----
| $ ps awlx | grep emacs
| 0  9772 11777     1  20   0  51284 32660 -      R    ?          1:02 
/usr/local/bin/emacs
`----

shows me that emacs is consuming roughly 32Mb. I have 1Gb of memory on
the machine, so that's a comfortable fit (about 1/30 of available
memory: leaves just enough space for X and firefox :-) ). If your
numbers are closer, then maybe that's a problem: in particular, if your
disk goes wild while emacs is trying to do its thing, you are probably
swapping heavily and your performance will *really* be in the
toilet. The only solution is to buy more memory (assuming your machine
can handle it.)

I should say that I know very little about Darwin, so all of the above
is pure speculation. Parts of it may be applicable: you'd need to check
with an OSX expert for more details.

If there are no problems of the sort described above, I would ask in an
emacs forum about the performance of the display engine on Darwin: do
other people see the slowness? It would show up even without org
(although org make the situation marginally worse to be sure.)  Given
the font-lock setting that Bernt dug up, it seems likely that if memory
is not the problem, the display engine is.

HTH,
Nick





reply via email to

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