* Extremely slow org-table operations
@ 2014-10-29 3:00 York Zhao
2014-10-29 9:43 ` Nicolas Goaziou
0 siblings, 1 reply; 14+ messages in thread
From: York Zhao @ 2014-10-29 3:00 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]
Hi list,
A few months ago I tried Emacs 24.4 and was disappointed because almost all of
the org-table operations became AT LEAST ten times slower. Because recently
Emacs 24.4 gets officially released, I finally switched over. However, the
problems I had several months ago were still there, i.e., in a big file,
org-table operations are at least ten times slower. I tried profiling it but
didn't help much. So I decided to report the issue here.
I've created an ECM, please find attached the zip file which includes four
files:
1. test-org: a bash simple script file having a single line:
emacs -Q --load test.el
2. test.el, with the following contents:
(find-file "test.org")
(show-all)
(goto-char (point-max))
(forward-line -1)
(profiler-start 'cpu)
(org-ctrl-c-ctrl-c)
(profiler-report)
(profiler-stop)
3. test.org: the org-mode file to reproduce the issue.
4. profiler-report: the "Profiler Report" file
This file was created by pressing "C-x C-w" (as described in the Elisp Info)
from a profile report buffer. However, I have no idea how to reproduce the
"Profiler Report Buffer" from this file. I've tried M-x profiler-report-mode
but it didn't work. If anyone knows how, please let me know and I would
appreciate it.
In summery, the file "test.org" has more than 5000 org-table tables, each table
has a formula. If you move the point to the tables not too far away from the
beginning of the buffer and press "C-c C-c" on the formula line, you will notice
that the speed is very fast which is great. However, if you move the point far
away enough from the beginning of the buffer (move to the end for example), you
will find that "C-c C-c" on the formula line becomes much slower.
Many other operations are also very slow. However, because I haven't been able
to create the ECMs for those operations yet, lets focus on this one first.
Please let me know what else I can do to help addressing this issue.
Thanks in advance,
York
[-- Attachment #2: Test.zip --]
[-- Type: application/zip, Size: 29532 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Extremely slow org-table operations
2014-10-29 3:00 Extremely slow org-table operations York Zhao
@ 2014-10-29 9:43 ` Nicolas Goaziou
2014-10-29 23:22 ` York Zhao
0 siblings, 1 reply; 14+ messages in thread
From: Nicolas Goaziou @ 2014-10-29 9:43 UTC (permalink / raw)
To: York Zhao; +Cc: emacs-orgmode
Hello,
York Zhao <gtdplatform@gmail.com> writes:
> A few months ago I tried Emacs 24.4 and was disappointed because almost all of
> the org-table operations became AT LEAST ten times slower. Because recently
> Emacs 24.4 gets officially released, I finally switched over. However, the
> problems I had several months ago were still there, i.e., in a big file,
> org-table operations are at least ten times slower. I tried profiling it but
> didn't help much. So I decided to report the issue here.
[...]
> In summery, the file "test.org" has more than 5000 org-table tables, each table
> has a formula. If you move the point to the tables not too far away from the
> beginning of the buffer and press "C-c C-c" on the formula line, you will notice
> that the speed is very fast which is great. However, if you move the point far
> away enough from the beginning of the buffer (move to the end for example), you
> will find that "C-c C-c" on the formula line becomes much slower.
>
> Many other operations are also very slow. However, because I haven't been able
> to create the ECMs for those operations yet, lets focus on this one
> first.
I think Org 8.3 should improve the situation. Please test it if you can.
Meanwhile, I suggest to insert some subsections in your file.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Extremely slow org-table operations
2014-10-29 9:43 ` Nicolas Goaziou
@ 2014-10-29 23:22 ` York Zhao
2014-10-29 23:40 ` Charles Millar
0 siblings, 1 reply; 14+ messages in thread
From: York Zhao @ 2014-10-29 23:22 UTC (permalink / raw)
To: York Zhao, emacs-orgmode
> I think Org 8.3 should improve the situation. Please test it if you can.
I was aware that my "emacs -Q" test was done against org-mode version 8.2.x.
However, I use the latest org-mode from Git everyday. For example, the version
I'm currently using is (from M-x org-version): "Org-mode version 8.3beta
(release_8.3beta-509-g86ec0a.dirty @ /usr/local/share/emacs/site-lisp/org/)". So
apparently the problem had never been addressed.
> Meanwhile, I suggest to insert some subsections in your file.
What do you mean by "insert some subsections"?
Thanks
On Wed, Oct 29, 2014 at 5:43 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> Hello,
>
> York Zhao <gtdplatform@gmail.com> writes:
>
>> A few months ago I tried Emacs 24.4 and was disappointed because almost all of
>> the org-table operations became AT LEAST ten times slower. Because recently
>> Emacs 24.4 gets officially released, I finally switched over. However, the
>> problems I had several months ago were still there, i.e., in a big file,
>> org-table operations are at least ten times slower. I tried profiling it but
>> didn't help much. So I decided to report the issue here.
>
> [...]
>
>> In summery, the file "test.org" has more than 5000 org-table tables, each table
>> has a formula. If you move the point to the tables not too far away from the
>> beginning of the buffer and press "C-c C-c" on the formula line, you will notice
>> that the speed is very fast which is great. However, if you move the point far
>> away enough from the beginning of the buffer (move to the end for example), you
>> will find that "C-c C-c" on the formula line becomes much slower.
>>
>> Many other operations are also very slow. However, because I haven't been able
>> to create the ECMs for those operations yet, lets focus on this one
>> first.
>
> I think Org 8.3 should improve the situation. Please test it if you can.
> Meanwhile, I suggest to insert some subsections in your file.
>
>
> Regards,
>
> --
> Nicolas Goaziou
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Extremely slow org-table operations
2014-10-29 23:22 ` York Zhao
@ 2014-10-29 23:40 ` Charles Millar
2014-10-30 6:47 ` Michael Brand
2014-10-30 14:38 ` York Zhao
0 siblings, 2 replies; 14+ messages in thread
From: Charles Millar @ 2014-10-29 23:40 UTC (permalink / raw)
To: emacs-orgmode
Hi,
York Zhao wrote:
>> I think Org 8.3 should improve the situation. Please test it if you can.
> I was aware that my "emacs -Q" test was done against org-mode version 8.2.x.
> However, I use the latest org-mode from Git everyday. For example, the version
> I'm currently using is (from M-x org-version): "Org-mode version 8.3beta
> (release_8.3beta-509-g86ec0a.dirty @ /usr/local/share/emacs/site-lisp/org/)". So
> apparently the problem had never been addressed.
>
>> Meanwhile, I suggest to insert some subsections in your file.
> What do you mean by "insert some subsections"?
>
>
> Thanks
>
>
> On Wed, Oct 29, 2014 at 5:43 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>> Hello,
>>
>> York Zhao <gtdplatform@gmail.com> writes:
>>
>>> A few months ago I tried Emacs 24.4 and was disappointed because almost all of
>>> the org-table operations became AT LEAST ten times slower. Because recently
>>> Emacs 24.4 gets officially released, I finally switched over. However, the
>>> problems I had several months ago were still there, i.e., in a big file,
>>> org-table operations are at least ten times slower. I tried profiling it but
>>> didn't help much. So I decided to report the issue here.
>> [...]
>>
>>> In summery, the file "test.org" has more than 5000 org-table tables, each table
>>> has a formula. If you move the point to the tables not too far away from the
>>> beginning of the buffer and press "C-c C-c" on the formula line, you will notice
>>> that the speed is very fast which is great. However, if you move the point far
>>> away enough from the beginning of the buffer (move to the end for example), you
>>> will find that "C-c C-c" on the formula line becomes much slower.
>>>
>>> Many other operations are also very slow. However, because I haven't been able
>>> to create the ECMs for those operations yet, lets focus on this one
>>> first.
>> I think Org 8.3 should improve the situation. Please test it if you can.
>> Meanwhile, I suggest to insert some subsections in your file.
>>
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>
IIRC Carsten Dominik made the following observation: org tables are
extremely slow if they are used as workbooks/spreadsheets and there are
many entries (many is undefined). He recommended that a spreadsheet
program in such situations.
I learned that the hard way when I had one table - four columns, three
simple addition formulas with about 1,000 entries. It seemed an eternity
before the addition was completed.
Charlie Millar
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Extremely slow org-table operations
2014-10-29 23:40 ` Charles Millar
@ 2014-10-30 6:47 ` Michael Brand
2014-10-30 12:39 ` Charles Millar
` (2 more replies)
2014-10-30 14:38 ` York Zhao
1 sibling, 3 replies; 14+ messages in thread
From: Michael Brand @ 2014-10-30 6:47 UTC (permalink / raw)
To: Charles Millar; +Cc: Org Mode
Hi Charles
First I would like to point out that to my understanding there are now
two separate issues in discussion in this thread which are easy to mix
up:
1) The same table calculates fast or slow depending on the position
within the same entry, see OP.
2) An entry with nothing but a single table, as you describe it:
On Thu, Oct 30, 2014 at 12:40 AM, Charles Millar <millarc@verizon.net> wrote:
> I learned that the hard way when I had one table - four columns, three
> simple addition formulas with about 1,000 entries. It seemed an eternity
> before the addition was completed.
Only out of curiosity I would like to see the TBLFM. And do you see
still the same slowness with 8.3beta?
Michael
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Extremely slow org-table operations
2014-10-30 6:47 ` Michael Brand
@ 2014-10-30 12:39 ` Charles Millar
2014-10-30 15:13 ` Fwd: " Charles Millar
2014-10-30 19:19 ` Charles Millar
2014-10-30 15:54 ` Nicolas Goaziou
2014-10-30 20:07 ` Charles Millar
2 siblings, 2 replies; 14+ messages in thread
From: Charles Millar @ 2014-10-30 12:39 UTC (permalink / raw)
To: Michael Brand, Org Mode
Hi Michael,
Michael Brand wrote:
> Hi Charles
>
> First I would like to point out that to my understanding there are now
> two separate issues in discussion in this thread which are easy to mix
> up:
>
> 1) The same table calculates fast or slow depending on the position
> within the same entry, see OP.
I did not understand; I thought that the speed slowed down as the OP
progressed from table to table in the file.
> 2) An entry with nothing but a single table, as you describe it:
True; I did not bother to mention other files in which I had multiple
tables, some with references to other tables in the file. At times "M-x
org-table-iterate-buffer-tables" seemed to take eternity, squared.
(Imagine a smiley face placed here.)
> On Thu, Oct 30, 2014 at 12:40 AM, Charles Millar <millarc@verizon.net> wrote:
>> I learned that the hard way when I had one table - four columns, three
>> simple addition formulas with about 1,000 entries. It seemed an eternity
>> before the addition was completed.
> Only out of curiosity I would like to see the TBLFM. And do you see
> still the same slowness with 8.3beta?
It has been quite a while and I suspect that my experience may have been
with org <8.0. I try to find the older files, give them a run and let
you know. I will also give org another shot using multiple tables, as
spreadsheets, in one file. The worst that can happen is that I will have
to export the tables.
Charlie
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Extremely slow org-table operations
2014-10-29 23:40 ` Charles Millar
2014-10-30 6:47 ` Michael Brand
@ 2014-10-30 14:38 ` York Zhao
2014-10-31 19:12 ` Charles Millar
1 sibling, 1 reply; 14+ messages in thread
From: York Zhao @ 2014-10-30 14:38 UTC (permalink / raw)
To: Charles Millar; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 3329 bytes --]
@Charlie Millar:
> IIRC Carsten Dominik made the following observation: org tables are
extremely
> slow if they are used as workbooks/spreadsheets and there are many entries
> (many is undefined).
Thanks for the information, could you please clarify what "entry" means?
Does it
mean org headline, or a row in an org-table?
> I learned that the hard way when I had one table - four columns, three
simple
> addition formulas with about 1,000 entries. It seemed an eternity before
the
> addition was completed.
I guess the "entries" here mean the table rows right? Please confirm.
York
On Wed, Oct 29, 2014 at 7:40 PM, Charles Millar <millarc@verizon.net> wrote:
> Hi,
>
>
> York Zhao wrote:
>
>> I think Org 8.3 should improve the situation. Please test it if you can.
>>>
>> I was aware that my "emacs -Q" test was done against org-mode version
>> 8.2.x.
>> However, I use the latest org-mode from Git everyday. For example, the
>> version
>> I'm currently using is (from M-x org-version): "Org-mode version 8.3beta
>> (release_8.3beta-509-g86ec0a.dirty @ /usr/local/share/emacs/site-lisp/org/)".
>> So
>> apparently the problem had never been addressed.
>>
>> Meanwhile, I suggest to insert some subsections in your file.
>>>
>> What do you mean by "insert some subsections"?
>>
>>
>> Thanks
>>
>>
>> On Wed, Oct 29, 2014 at 5:43 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
>> wrote:
>>
>>> Hello,
>>>
>>> York Zhao <gtdplatform@gmail.com> writes:
>>>
>>> A few months ago I tried Emacs 24.4 and was disappointed because almost
>>>> all of
>>>> the org-table operations became AT LEAST ten times slower. Because
>>>> recently
>>>> Emacs 24.4 gets officially released, I finally switched over. However,
>>>> the
>>>> problems I had several months ago were still there, i.e., in a big file,
>>>> org-table operations are at least ten times slower. I tried profiling
>>>> it but
>>>> didn't help much. So I decided to report the issue here.
>>>>
>>> [...]
>>>
>>> In summery, the file "test.org" has more than 5000 org-table tables,
>>>> each table
>>>> has a formula. If you move the point to the tables not too far away
>>>> from the
>>>> beginning of the buffer and press "C-c C-c" on the formula line, you
>>>> will notice
>>>> that the speed is very fast which is great. However, if you move the
>>>> point far
>>>> away enough from the beginning of the buffer (move to the end for
>>>> example), you
>>>> will find that "C-c C-c" on the formula line becomes much slower.
>>>>
>>>> Many other operations are also very slow. However, because I haven't
>>>> been able
>>>> to create the ECMs for those operations yet, lets focus on this one
>>>> first.
>>>>
>>> I think Org 8.3 should improve the situation. Please test it if you can.
>>> Meanwhile, I suggest to insert some subsections in your file.
>>>
>>>
>>> Regards,
>>>
>>> --
>>> Nicolas Goaziou
>>>
>>
>> IIRC Carsten Dominik made the following observation: org tables are
> extremely slow if they are used as workbooks/spreadsheets and there are
> many entries (many is undefined). He recommended that a spreadsheet program
> in such situations.
>
> I learned that the hard way when I had one table - four columns, three
> simple addition formulas with about 1,000 entries. It seemed an eternity
> before the addition was completed.
>
> Charlie Millar
>
>
[-- Attachment #2: Type: text/html, Size: 4708 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Fwd: Re: Extremely slow org-table operations
2014-10-30 12:39 ` Charles Millar
@ 2014-10-30 15:13 ` Charles Millar
2014-10-30 19:19 ` Charles Millar
1 sibling, 0 replies; 14+ messages in thread
From: Charles Millar @ 2014-10-30 15:13 UTC (permalink / raw)
To: em >> Org Mode
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: Re: [O] Extremely slow org-table operations.eml --]
[-- Type: message/rfc822, Size: 2287 bytes --]
From: Charles Millar <millarc@verizon.net>
To: Michael Brand <michael.ch.brand@gmail.com>, Org Mode <emacs-orgmode@gnu.org>
Subject: Re: [O] Extremely slow org-table operations
Date: Thu, 30 Oct 2014 08:39:11 -0400
Message-ID: <5452316F.5060203@verizon.net>
Hi Michael,
Michael Brand wrote:
> Hi Charles
>
> First I would like to point out that to my understanding there are now
> two separate issues in discussion in this thread which are easy to mix
> up:
>
> 1) The same table calculates fast or slow depending on the position
> within the same entry, see OP.
I did not understand; I thought that the speed slowed down as the OP
progressed from table to table in the file.
> 2) An entry with nothing but a single table, as you describe it:
True; I did not bother to mention other files in which I had multiple
tables, some with references to other tables in the file. At times "M-x
org-table-iterate-buffer-tables" seemed to take eternity, squared.
(Imagine a smiley face placed here.)
> On Thu, Oct 30, 2014 at 12:40 AM, Charles Millar <millarc@verizon.net> wrote:
>> I learned that the hard way when I had one table - four columns, three
>> simple addition formulas with about 1,000 entries. It seemed an eternity
>> before the addition was completed.
> Only out of curiosity I would like to see the TBLFM. And do you see
> still the same slowness with 8.3beta?
It has been quite a while and I suspect that my experience may have been
with org <8.0. I try to find the older files, give them a run and let
you know. I will also give org another shot using multiple tables, as
spreadsheets, in one file. The worst that can happen is that I will have
to export the tables.
Charlie
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Extremely slow org-table operations
2014-10-30 6:47 ` Michael Brand
2014-10-30 12:39 ` Charles Millar
@ 2014-10-30 15:54 ` Nicolas Goaziou
2014-10-30 20:07 ` Charles Millar
2 siblings, 0 replies; 14+ messages in thread
From: Nicolas Goaziou @ 2014-10-30 15:54 UTC (permalink / raw)
To: Michael Brand; +Cc: Org Mode, Charles Millar
Hello,
Michael Brand <michael.ch.brand@gmail.com> writes:
> 1) The same table calculates fast or slow depending on the position
> within the same entry, see OP.
Note that this is due to org-table.el overusing `org-current-line'. It
should be factored out of the library at some point.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Extremely slow org-table operations
2014-10-30 12:39 ` Charles Millar
2014-10-30 15:13 ` Fwd: " Charles Millar
@ 2014-10-30 19:19 ` Charles Millar
1 sibling, 0 replies; 14+ messages in thread
From: Charles Millar @ 2014-10-30 19:19 UTC (permalink / raw)
To: Org Mode
Earlier today I attempted to send the following.
Charles Millar wrote:
> Hi Michael,
>
> Michael Brand wrote:
>> Hi Charles
>>
>> First I would like to point out that to my understanding there are now
>> two separate issues in discussion in this thread which are easy to mix
>> up:
>>
>> 1) The same table calculates fast or slow depending on the position
>> within the same entry, see OP.
> I did not understand; I thought that the speed slowed down as the OP
> progressed from table to table in the file.
>> 2) An entry with nothing but a single table, as you describe it:
> True; I did not bother to mention other files in which I had multiple
> tables, some with references to other tables in the file. At times
> "M-x org-table-iterate-buffer-tables" seemed to take eternity,
> squared. (Imagine a smiley face placed here.)
>> On Thu, Oct 30, 2014 at 12:40 AM, Charles Millar
>> <millarc@verizon.net> wrote:
>>> I learned that the hard way when I had one table - four columns, three
>>> simple addition formulas with about 1,000 entries. It seemed an
>>> eternity
>>> before the addition was completed.
>> Only out of curiosity I would like to see the TBLFM. And do you see
>> still the same slowness with 8.3beta?
> It has been quite a while and I suspect that my experience may have
> been with org <8.0. I try to find the older files, give them a run and
> let you know. I will also give org another shot using multiple
> tables, as spreadsheets, in one file. The worst that can happen is
> that I will have to export the tables.
>
> Charlie
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Extremely slow org-table operations
2014-10-30 6:47 ` Michael Brand
2014-10-30 12:39 ` Charles Millar
2014-10-30 15:54 ` Nicolas Goaziou
@ 2014-10-30 20:07 ` Charles Millar
2 siblings, 0 replies; 14+ messages in thread
From: Charles Millar @ 2014-10-30 20:07 UTC (permalink / raw)
To: emacs-orgmode
Hi Michael
> Michael Brand wrote:
>> Hi Charles
>>
>> First I would like to point out that to my understanding there are now
>> two separate issues in discussion in this thread which are easy to mix
>> up:
>>
>> 1) The same table calculates fast or slow depending on the position
>> within the same entry, see OP.
> I did not understand; I thought that the speed slowed down as the OP
progressed from table to table in the file.
>> 2) An entry with nothing but a single table, as you describe it:
> True; I did not bother to mention other files in which I had multiple
tables, some with references to other tables in the file. At times "M-x
org-table-iterate-buffer-tables" seemed to take eternity, squared.
(Imagine a smiley face placed here.)
>> On Thu, Oct 30, 2014 at 12:40 AM, Charles Millar
<millarc@verizon.net> wrote:
>>> I learned that the hard way when I had one table - four columns, three
>>> simple addition formulas with about 1,000 entries. It seemed an
eternity
>>> before the addition was completed.
>> Only out of curiosity I would like to see the TBLFM. And do you see
>> still the same slowness with 8.3beta?
> It has been quite a while and I suspect that my experience may have
been with org <8.0. I try to find the older files, give them a run and
let you know. I will also give org another shot using multiple tables,
as spreadsheets, in one file. The worst that can happen is that I will
have to export the tables.
>
> Charlie
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Extremely slow org-table operations
2014-10-30 14:38 ` York Zhao
@ 2014-10-31 19:12 ` Charles Millar
2014-11-08 15:25 ` York Zhao
0 siblings, 1 reply; 14+ messages in thread
From: Charles Millar @ 2014-10-31 19:12 UTC (permalink / raw)
To: York Zhao, emacs-orgmode
Hi York,
York Zhao wrote:
> @Charlie Millar:
>
> > IIRC Carsten Dominik made the following observation: org tables are
> extremely
> > slow if they are used as workbooks/spreadsheets and there are many
> entries
> > (many is undefined).
>
> Thanks for the information, could you please clarify what "entry"
> means? Does it
> mean org headline, or a row in an org-table?
>
> > I learned that the hard way when I had one table - four columns,
> three simple
> > addition formulas with about 1,000 entries. It seemed an eternity
> before the
> > addition was completed.
>
> I guess the "entries" here mean the table rows right? Please confirm.
>
You are correct; I should have said rows. In my file there were 1000
(+/-) rows and each row had up to three "entries", not including the
description in the first row.
For instance (without any formulas) in the following row I entered each
amount in columns 2,3 & 4.
| this was a transaction | 100.00 | 200.00 | 300.00|
So I considered this three entries. So actually there were 3,000 (+/-)
entries.
Charlie
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Extremely slow org-table operations
2014-10-31 19:12 ` Charles Millar
@ 2014-11-08 15:25 ` York Zhao
2014-11-08 20:34 ` Nicolas Goaziou
0 siblings, 1 reply; 14+ messages in thread
From: York Zhao @ 2014-11-08 15:25 UTC (permalink / raw)
To: Charles Millar; +Cc: emacs-orgmode
>> > I learned that the hard way when I had one table - four columns, three
>> > simple
>> > addition formulas with about 1,000 entries. It seemed an eternity before
>> > the
>> > addition was completed.
>>
>> I guess the "entries" here mean the table rows right? Please confirm.
>>
> You are correct; I should have said rows. In my file there were 1000 (+/-)
> rows and each row had up to three "entries", not including the description
> in the first row.
> For instance (without any formulas) in the following row I entered each
> amount in columns 2,3 & 4.
>
> | this was a transaction | 100.00 | 200.00 | 300.00|
>
> So I considered this three entries. So actually there were 3,000 (+/-)
> entries.
OK, now I see. Charlie's problem is actually completed different from this
problem. So what Carsten Dominik mentioned doesn't apply. This is because in
Charlie's case there are 1000 rows in a table, whereas mine has only two rows.
Since my formula only calculates two rows, and calculating the table doesn't
involve data input from anywhere else, it really doesn't make sens that it has
to be slow.
Needlessly to say that `org-mode' is fantastic, but with this issue, I have to
say that `org-mode' is unhealthy. Therefore, I really hope this issue gets
addressed. Please let me know what I can do to help.
Thanks in advance,
York
On Fri, Oct 31, 2014 at 3:12 PM, Charles Millar <millarc@verizon.net> wrote:
> Hi York,
>
> York Zhao wrote:
>>
>> @Charlie Millar:
>>
>> > IIRC Carsten Dominik made the following observation: org tables are
>> > extremely
>> > slow if they are used as workbooks/spreadsheets and there are many
>> > entries
>> > (many is undefined).
>>
>> Thanks for the information, could you please clarify what "entry" means?
>> Does it
>> mean org headline, or a row in an org-table?
>>
>> > I learned that the hard way when I had one table - four columns, three
>> > simple
>> > addition formulas with about 1,000 entries. It seemed an eternity before
>> > the
>> > addition was completed.
>>
>> I guess the "entries" here mean the table rows right? Please confirm.
>>
> You are correct; I should have said rows. In my file there were 1000 (+/-)
> rows and each row had up to three "entries", not including the description
> in the first row.
> For instance (without any formulas) in the following row I entered each
> amount in columns 2,3 & 4.
>
> | this was a transaction | 100.00 | 200.00 | 300.00|
>
> So I considered this three entries. So actually there were 3,000 (+/-)
> entries.
>
> Charlie
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Extremely slow org-table operations
2014-11-08 15:25 ` York Zhao
@ 2014-11-08 20:34 ` Nicolas Goaziou
0 siblings, 0 replies; 14+ messages in thread
From: Nicolas Goaziou @ 2014-11-08 20:34 UTC (permalink / raw)
To: York Zhao; +Cc: emacs-orgmode, Charles Millar
York Zhao <gtdplatform@gmail.com> writes:
> Needlessly to say that `org-mode' is fantastic, but with this issue, I have to
> say that `org-mode' is unhealthy. Therefore, I really hope this issue gets
> addressed. Please let me know what I can do to help.
With your initial file, benchmarking a C-c C-c on the last table, I get:
Elapsed time: 2.129800s
This is not fast, but nothing unbearable either. The same on the first
table gives
Elapsed time: 1.195026s
As I said in this thread, the additional cost comes from the use of
`org-current-line' in "org-table.el".
Regards,
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2014-11-08 20:34 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-29 3:00 Extremely slow org-table operations York Zhao
2014-10-29 9:43 ` Nicolas Goaziou
2014-10-29 23:22 ` York Zhao
2014-10-29 23:40 ` Charles Millar
2014-10-30 6:47 ` Michael Brand
2014-10-30 12:39 ` Charles Millar
2014-10-30 15:13 ` Fwd: " Charles Millar
2014-10-30 19:19 ` Charles Millar
2014-10-30 15:54 ` Nicolas Goaziou
2014-10-30 20:07 ` Charles Millar
2014-10-30 14:38 ` York Zhao
2014-10-31 19:12 ` Charles Millar
2014-11-08 15:25 ` York Zhao
2014-11-08 20:34 ` Nicolas Goaziou
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).