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

[Marcelo de Moraes Serpa]

HI Nicholas, thanks for the reply,

>How long does it take for emacs to show
>you the file?

>From the moment I press <enter> on the minibuffer to the moment the
whole file is rendered, it takes about 3 seconds. So, it does take
longer than I would expect.

I have a 10-months old Macbook, and its specs are quite recent, check
out (from System Profiler):

  Model Name:   MacBook
  Model Identifier:     MacBook6,1
  Processor Name:       Intel Core 2 Duo
  Processor Speed:      2.26 GHz
  Number Of Processors: 1
  Total Number Of Cores:        2
  L2 Cache:     3 MB
  Memory:       4 GB
  Bus Speed:    1.07 GHz
  Boot ROM Version:     MB61.00C8.B00
  SMC Version (system): 1.51f53
  Serial Number (system):       W89483Q78PX
  Hardware UUID:        413C6EF2-12B3-5C38-A3CA-5A1F924867D7
  Sudden Motion Sensor:
  State:        Enabled

So, the system is quite capable and is definetly should not be the bottleneck.

What I note though is that when I open this big org file and try to
naviagate around, the Emacs.app CPU usage goes up to 100% and then
gradually goes down to 0 as I stop giving any other commands. Check
out the screenshot below:

http://i56.tinypic.com/123sbcj.png

When I run "ps awlx | grep emacs", I get the following output:

 >501  5733  5578   0  31  0  2425520    168 -      R+   s000
0:00.00 grep emacs

Some additional information:

Emacs version string:

>GNU Emacs 23.2.1 (x86_64-apple-darwin, NS apple-appkit-1038.29) of 2010-05-08 
>on black.local

Org-mode version string:

>Org-mode version 7.01trans (release_7.01g.20.gdd484.dirty)

It is really unfortunate that org-mode runs like this on OSX. I can't
really think of anything else I could use to manage my personal
information and todo lists, but handling big orgfiles, as of now, is
really starting to be a blocker :-(

Thanks for the help,

Marcelo.


On Sun, Sep 5, 2010 at 9:07 PM, Nick Dokos <address@hidden> wrote:
> 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
>
>
>