[-- Attachment #1: Type: text/plain, Size: 555 bytes --] Hi list, I love org and I think there's nothing like it out there, but I'm considering using Evernote for reference notes, because my reference.orgfile has grown too big (4234k + lines). This makes the rendering of the file way too slow, and 2 times out of 10 emacs crashes because of that. What could I do to make it faster? I'm willing to disable fancy rendering features if needed, but I'm loosing way too much time with the rendering issues and crashes. I'm using emacs 23.3.1 on Lion, org version 7.4. Any hints appreciated. Cheers. - Marcelo. [-- Attachment #2: Type: text/html, Size: 656 bytes --]
* Maybe EMACS "narrowing" could be used: http://www.gnu.org/s/libtool/manual/emacs/Narrowing.html ... Narrowing can make it easier to concentrate on a single subroutine or paragraph by eliminating clutter. It can also be used to limit the range of operation of a replace command or repeating keyboard macro. ... C-x n n Narrow down to between point and mark (narrow-to-region). C-x n w Widen to make the entire buffer accessible again (widen). C-x n p Narrow down to the current page (narrow-to-page). C-x n d Narrow down to the current defun (narrow-to-defun). ** I mean: Maybe an OrgMode user could do narrow-to-region (and then just "render" on the new smaller region) and/or an implementation something like "org-narrow-to-region" could be coded. *** Just an idea--your mileage may vary--it may not work at all--I hope you try it out and tell how it works for you. * I ran into similar problems: I made the file into 2 separate files--one very large and the other very small that I render a lot--when it gets big, I just prune out older and less important now (backburner) subjects, paste them at the bottom of the small file and then cut and paste the less important "*" sections into the big file. ** Works great, its really the best way to do it--for backing up and encrypting reasons and hard drive space reasons etc. ** Could call them blahfile_now.org and blahfile_later.org (for the small and large files respectively). *** Since OrgMode files are plain text files, this works great. On Wed, Oct 12, 2011 at 8:54 PM, Marcelo de Moraes Serpa <celoserpa@gmail.com> wrote: > Hi list, > > I love org and I think there's nothing like it out there, but I'm > considering using Evernote for reference notes, because my reference.org > file has grown too big (4234k + lines). This makes the rendering of the file > way too slow, and 2 times out of 10 emacs crashes because of that.
brian powell <briangpowellms@gmail.com> writes: > * I ran into similar problems: I made the file into 2 separate > files--one very large and the other very small that I render a > lot--when it gets big, I just prune out older and less important now > (backburner) subjects, paste them at the bottom of the small file and > then cut and paste the less important "*" sections into the big file. > ** Works great, its really the best way to do it--for backing up and > encrypting reasons and hard drive space reasons etc. > ** Could call them blahfile_now.org and blahfile_later.org (for the > small and large files respectively). > *** Since OrgMode files are plain text files, this works great. This works for me, too. I use the archive facility. When I'm done with a tree in the small file, I C-c C-x C-a on the headline, which saves having to cut and paste. Tom -- Thomas S. Dye http://www.tsdye.com
Hi,
On 10/13/2011 09:54 AM, Marcelo de Moraes Serpa wrote:
f 10 emacs crashes because of that.
>
> What could I do to make it faster? I'm willing to disable fancy rendering
> features if needed, but I'm loosing way too much time with the rendering
> issues and crashes.
Just by chance, are you running linum-mode (line numbers in a small
column at the left side of the buffer?
I noticed this does not work well with org-mode. I had a file with a few
thousand lines and folding took ages.
Switching the linum-mode off and folding was again instantly.
Maybe this helps
Totti
[-- Attachment #1: Type: text/plain, Size: 768 bytes --] Wow.. this worked Torsten. Thank you. I wonder why this happens... On Wed, Oct 12, 2011 at 9:44 PM, Torsten Wagner <torsten.wagner@gmail.com>wrote: > Hi, > > > On 10/13/2011 09:54 AM, Marcelo de Moraes Serpa wrote: > f 10 emacs crashes because of that. > >> >> What could I do to make it faster? I'm willing to disable fancy rendering >> features if needed, but I'm loosing way too much time with the rendering >> issues and crashes. >> > > Just by chance, are you running linum-mode (line numbers in a small column > at the left side of the buffer? > I noticed this does not work well with org-mode. I had a file with a few > thousand lines and folding took ages. > Switching the linum-mode off and folding was again instantly. > > Maybe this helps > > Totti > > > [-- Attachment #2: Type: text/html, Size: 1200 bytes --]
Marcelo de Moraes Serpa <celoserpa@gmail.com> writes:
> Wow.. this worked Torsten. Thank you. I wonder why this happens...
linum-mode works with overlays to embed the numbers at the beginnig of
lines. Overlays are very flexible but not too efficient, you don't want
to have too many of them. Looking at linum.el, it seems it already does
pooling of overlays in order not to create one overlay for any line, but
I'm not sure. Could you please do
M-: (length linum-overlays) RET
in that large org file with linum-mode enabled and say what it returns
to satisfy my curiosity?
Bye,
Tassilo
* Marcelo de Moraes Serpa <celoserpa@gmail.com> wrote: > > Hi list, Hi individual! > I love org and I think there's nothing like it out there, Ack! > but I'm considering using Evernote for reference notes, because my > reference.orgfile has grown too big (4234k + lines). This makes > the rendering of the file way too slow, and 2 times out of 10 > emacs crashes because of that. Not exactly the topic you mentioned but as a side mark to crashes on Mac OS X I want to add: I am trying to implement life-logging [1] with Org-mode and GNU Emacs. Therefore I created [2]. Even in this early stage, it ends up with >150.000 lines in approx. 30 Org-mode files. Most of them are in «*.org_archive» files though. (Further performance information: [3]) On my notebook I am using GNU Linux (Ubuntu 11.04) with GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.24.4). At home I've got Mac OS X 10.5 with http://emacsformacosx.com/ (sorry, no detailed version number since I am currently sitting in my office *g*). I never noticed *any* crash of Emacs using Org-mode on my Linux machine. But on my OS X box, I notice crashes many times. Mostly when navigating (vertically or horizontally) in the Agenda view. Maybe there is an (hidden?) issue with GNU Emacs on OS X (too). 1. http://en.wikipedia.org/wiki/Lifelogging 2. https://github.com/novoid/Memacs 3. https://github.com/novoid/Memacs/blob/master/FAQs_and_Best_Practices.org -- Karl Voit
Hi Karl Karl Voit <devnull@Karl-Voit.at> writes: > * Marcelo de Moraes Serpa <celoserpa@gmail.com> wrote: >> >> Hi list, > > Hi individual! > >> I love org and I think there's nothing like it out there, > > Ack! > >> but I'm considering using Evernote for reference notes, because my >> reference.orgfile has grown too big (4234k + lines). This makes >> the rendering of the file way too slow, and 2 times out of 10 >> emacs crashes because of that. > > Not exactly the topic you mentioned but as a side mark to crashes on > Mac OS X I want to add: > > I am trying to implement life-logging [1] with Org-mode and GNU > Emacs. Therefore I created [2]. Even in this early stage, it ends up > with >150.000 lines in approx. 30 Org-mode files. Most of them are > in «*.org_archive» files though. (Further performance information: > [3]) > > On my notebook I am using GNU Linux (Ubuntu 11.04) with GNU Emacs > 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.24.4). At home I've got > Mac OS X 10.5 with http://emacsformacosx.com/ (sorry, no detailed > version number since I am currently sitting in my office *g*). > > I never noticed *any* crash of Emacs using Org-mode on my Linux > machine. But on my OS X box, I notice crashes many times. Mostly > when navigating (vertically or horizontally) in the Agenda view. > > Maybe there is an (hidden?) issue with GNU Emacs on OS X (too). > Just for your information I use emacsformacosx port on Mac OS X 10.6.8, currently GNU Emacs 24.0.50.1 with 2GB RAM and 2.4GHz. On larger org files (over 13000 lines) navigation slows considerably, but I have never had Emacs crash, despite fairly heavy usage. However, I tend to maintain fairly compact files, through archiving. > 1. http://en.wikipedia.org/wiki/Lifelogging > 2. https://github.com/novoid/Memacs > 3. https://github.com/novoid/Memacs/blob/master/FAQs_and_Best_Practices.org mj --- Org-mode version 7.7 (release_7.7.359.g18e67) GNU Emacs 24.0.50.1 (x86_64-apple-darwin, NS apple-appkit-1038.35) of 2011-08-21 on virtualmac.porkrind.org
[-- Attachment #1: Type: text/plain, Size: 768 bytes --] 4328, exactly the same amount of lines I have in the file. On Thu, Oct 13, 2011 at 2:07 AM, Tassilo Horn <tassilo@member.fsf.org>wrote: > Marcelo de Moraes Serpa <celoserpa@gmail.com> writes: > > > Wow.. this worked Torsten. Thank you. I wonder why this happens... > > linum-mode works with overlays to embed the numbers at the beginnig of > lines. Overlays are very flexible but not too efficient, you don't want > to have too many of them. Looking at linum.el, it seems it already does > pooling of overlays in order not to create one overlay for any line, but > I'm not sure. Could you please do > > M-: (length linum-overlays) RET > > in that large org file with linum-mode enabled and say what it returns > to satisfy my curiosity? > > Bye, > Tassilo > > > [-- Attachment #2: Type: text/html, Size: 1179 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --] For my org files my linum-overlays length is equal to the number of lines on the screen so perhaps there's something you can do to get better performance. I'm not sure what setting it would be, I'm running e24 with my own complicated linum-format. Scott On Thu, Oct 13, 2011 at 9:23 PM, Marcelo de Moraes Serpa < celoserpa@gmail.com> wrote: > 4328, exactly the same amount of lines I have in the file. > > > On Thu, Oct 13, 2011 at 2:07 AM, Tassilo Horn <tassilo@member.fsf.org>wrote: > >> Marcelo de Moraes Serpa <celoserpa@gmail.com> writes: >> >> > Wow.. this worked Torsten. Thank you. I wonder why this happens... >> >> linum-mode works with overlays to embed the numbers at the beginnig of >> lines. Overlays are very flexible but not too efficient, you don't want >> to have too many of them. Looking at linum.el, it seems it already does >> pooling of overlays in order not to create one overlay for any line, but >> I'm not sure. Could you please do >> >> M-: (length linum-overlays) RET >> >> in that large org file with linum-mode enabled and say what it returns >> to satisfy my curiosity? >> >> Bye, >> Tassilo >> >> >> > [-- Attachment #2: Type: text/html, Size: 1869 bytes --]
* Karl Voit <devnull@Karl-Voit.at> wrote:
>
> On my notebook I am using GNU Linux (Ubuntu 11.04) with GNU Emacs
> 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.24.4). At home I've got
> Mac OS X 10.5 with http://emacsformacosx.com/ (sorry, no detailed
> version number since I am currently sitting in my office *g*).
Here is my GNU Emacs version:
GNU Emacs 23.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.35) of
2011-03-10 on black.porkrind.org)
--
Karl Voit
Hallo, mein Name ist Web 2.0. Gib mir dein Adressbuch und lass mich Emails lesen
Marcelo de Moraes Serpa <celoserpa@gmail.com> writes: Hi Marcelo, > 4328, exactly the same amount of lines I have in the file. Didn't you say that you have 4000 *k* lines? Anyway, as Scott mentiones, in emacs 24 the linum packages seems to be more clever and only creates overlays for the visible area of a buffer. For example, when opening a file with 1000 lines and enabling linum-mode, I only have 35 overlays, because only 35 lines are visible at a time. Bye, Tassilo > On Thu, Oct 13, 2011 at 2:07 AM, Tassilo Horn <tassilo@member.fsf.org>wrote: > >> Marcelo de Moraes Serpa <celoserpa@gmail.com> writes: >> >> > Wow.. this worked Torsten. Thank you. I wonder why this happens... >> >> linum-mode works with overlays to embed the numbers at the beginnig of >> lines. Overlays are very flexible but not too efficient, you don't want >> to have too many of them. Looking at linum.el, it seems it already does >> pooling of overlays in order not to create one overlay for any line, but >> I'm not sure. Could you please do >> >> M-: (length linum-overlays) RET >> >> in that large org file with linum-mode enabled and say what it returns >> to satisfy my curiosity? >> >> Bye, >> Tassilo >> >> >>
[-- Attachment #1: Type: text/plain, Size: 1416 bytes --] Btw I get that behavior in emacs 23.1 too Scott On Fri, Oct 14, 2011 at 3:00 AM, Tassilo Horn <tassilo@member.fsf.org>wrote: > Marcelo de Moraes Serpa <celoserpa@gmail.com> writes: > > Hi Marcelo, > > > 4328, exactly the same amount of lines I have in the file. > > Didn't you say that you have 4000 *k* lines? > > Anyway, as Scott mentiones, in emacs 24 the linum packages seems to be > more clever and only creates overlays for the visible area of a buffer. > For example, when opening a file with 1000 lines and enabling > linum-mode, I only have 35 overlays, because only 35 lines are visible > at a time. > > Bye, > Tassilo > > > On Thu, Oct 13, 2011 at 2:07 AM, Tassilo Horn <tassilo@member.fsf.org > >wrote: > > > >> Marcelo de Moraes Serpa <celoserpa@gmail.com> writes: > >> > >> > Wow.. this worked Torsten. Thank you. I wonder why this happens... > >> > >> linum-mode works with overlays to embed the numbers at the beginnig of > >> lines. Overlays are very flexible but not too efficient, you don't want > >> to have too many of them. Looking at linum.el, it seems it already does > >> pooling of overlays in order not to create one overlay for any line, but > >> I'm not sure. Could you please do > >> > >> M-: (length linum-overlays) RET > >> > >> in that large org file with linum-mode enabled and say what it returns > >> to satisfy my curiosity? > >> > >> Bye, > >> Tassilo > >> > >> > >> > > [-- Attachment #2: Type: text/html, Size: 2202 bytes --]
If org-mode runs into that kind of problem one way might be when a new
.org file is made it has a chained from [main.org] statement in the top.
If the file remains small enough that's all it would get. If the file
is going to go beyond x lines in length, then a chained to [file.org]
would end that first file and file.org would then open up if a user went
beyond the chained to statement in the first file. The file file.org
would have a chained from [firstfile.org] somewhere in the top of the
file and names for files ought to be selectable by the users. This will
only work where good garbage collection happens, and something like it
was used on CP/M systems with t-maker back before I.B.M. made its first
PC.
On Fri, 14 Oct 2011, Scott Jaderholm wrote:
> Btw I get that behavior in emacs 23.1 too
> Scott
>
>
> On Fri, Oct 14, 2011 at 3:00 AM, Tassilo Horn <tassilo@member.fsf.org>wrote:
>
> > Marcelo de Moraes Serpa <celoserpa@gmail.com> writes:
> >
> > Hi Marcelo,
> >
> > > 4328, exactly the same amount of lines I have in the file.
> >
> > Didn't you say that you have 4000 *k* lines?
> >
> > Anyway, as Scott mentiones, in emacs 24 the linum packages seems to be
> > more clever and only creates overlays for the visible area of a buffer.
> > For example, when opening a file with 1000 lines and enabling
> > linum-mode, I only have 35 overlays, because only 35 lines are visible
> > at a time.
> >
> > Bye,
> > Tassilo
> >
> > > On Thu, Oct 13, 2011 at 2:07 AM, Tassilo Horn <tassilo@member.fsf.org
> > >wrote:
> > >
> > >> Marcelo de Moraes Serpa <celoserpa@gmail.com> writes:
> > >>
> > >> > Wow.. this worked Torsten. Thank you. I wonder why this happens...
> > >>
> > >> linum-mode works with overlays to embed the numbers at the beginnig of
> > >> lines. Overlays are very flexible but not too efficient, you don't want
> > >> to have too many of them. Looking at linum.el, it seems it already does
> > >> pooling of overlays in order not to create one overlay for any line, but
> > >> I'm not sure. Could you please do
> > >>
> > >> M-: (length linum-overlays) RET
> > >>
> > >> in that large org file with linum-mode enabled and say what it returns
> > >> to satisfy my curiosity?
> > >>
> > >> Bye,
> > >> Tassilo
> > >>
> > >>
> > >>
> >
> >
>
Jude <jdashiel@shellworld.net>
If I got a nickel for every message I've already sent supporting Microsoft
Windows and its applications I'd have enough to retire on comfortably no
matter what the stock market did.
Why not working-file and archive-file? Archive-file would be the big
file and working-file would be the small file in that scheme.
On Wed, 12 Oct 2011, brian powell wrote:
> * Maybe EMACS "narrowing" could be used:
> http://www.gnu.org/s/libtool/manual/emacs/Narrowing.html
> ...
> Narrowing can make it easier to concentrate on a single subroutine or
> paragraph by eliminating clutter. It can also be used to limit the
> range of operation of a replace command or repeating keyboard macro.
> ...
> C-x n n
> Narrow down to between point and mark (narrow-to-region).
> C-x n w
> Widen to make the entire buffer accessible again (widen).
> C-x n p
> Narrow down to the current page (narrow-to-page).
> C-x n d
> Narrow down to the current defun (narrow-to-defun).
>
> ** I mean: Maybe an OrgMode user could do narrow-to-region (and then
> just "render" on the new smaller region) and/or an implementation
> something like "org-narrow-to-region" could be coded.
>
> *** Just an idea--your mileage may vary--it may not work at all--I
> hope you try it out and tell how it works for you.
>
> * I ran into similar problems: I made the file into 2 separate
> files--one very large and the other very small that I render a
> lot--when it gets big, I just prune out older and less important now
> (backburner) subjects, paste them at the bottom of the small file and
> then cut and paste the less important "*" sections into the big file.
> ** Works great, its really the best way to do it--for backing up and
> encrypting reasons and hard drive space reasons etc.
> ** Could call them blahfile_now.org and blahfile_later.org (for the
> small and large files respectively).
> *** Since OrgMode files are plain text files, this works great.
>
> On Wed, Oct 12, 2011 at 8:54 PM, Marcelo de Moraes Serpa
> <celoserpa@gmail.com> wrote:
> > Hi list,
> >
> > I love org and I think there's nothing like it out there, but I'm
> > considering using Evernote for reference notes, because my reference.org
> > file has grown too big (4234k + lines). This makes the rendering of the file
> > way too slow, and 2 times out of 10 emacs crashes because of that.
>
>
Jude <jdashiel@shellworld.net>
If I got a nickel for every message I've already sent supporting Microsoft
Windows and its applications I'd have enough to retire on comfortably no
matter what the stock market did.