From: Richard Lawrence <richard.lawrence@berkeley.edu>
To: emacs-orgmode@gnu.org
Subject: Bug?/performance issue in org-icalendar-export-current-agenda
Date: Tue, 26 Aug 2014 10:40:35 -0700 [thread overview]
Message-ID: <871ts3du98.fsf@berkeley.edu> (raw)
Hi all,
I pulled from master recently (for the first time since the spring), and
since the update, I have noticed a performance/lockup issue. The
problem occurs when exporting an agenda view to iCalendar format.
My Emacs version is 23.4.1 and my Org version is "8.3beta" (I am
currently on commit 767895...)
I have traced the problem down to a call to
`org-icalendar-export-current-agenda', though I don't know if the
problem is in this function or in another function called by it.
Somewhere during the execution of this function, Emacs goes to 100% CPU
usage (on one core) and memory usage starts growing until I kill the
process.
Here's what my setup looks like. I have just one entry in
`org-agenda-custom-commands' that defines the files field. It looks
like:
("Z" "Export to iCalendar file" tags "+event|+appointment" nil
("~/Documents/website/public_html/lib/attachments/calendar.ics")
I normally only call this command via a cron job that exports my agenda
files to .ics, which until recently was working fine. But I have
noticed I can reproduce the lockup interactively by building an agenda
view with this command, and then calling
`org-icalendar-export-current-agenda' on it (which is also what happens,
a few steps down the call chain, during the cron job).
I have run some tests by manually setting org-agenda-files, then
building this agenda and eval'ing
(org-icalendar-export-current-agenda "/tmp/agenda.ics")
in the agenda buffer. The results:
1) Using just a simple three-entry test file, the export completes quickly
and I don't see the lockup.
2) Using an agenda file which contains plenty of real data
(about 1000 lines) but no headlines tagged "event" or "appointment"
(i.e., a file for which this agenda view is empty), the call to
`org-icalendar-export-current-agenda' takes about 5 seconds to
complete, even though there are no entries to export. During those
5 seconds, the Emacs process goes to 100% CPU usage.
3) Using a different agenda file (of about 4000 lines) which contains
about 75 matching headlines, the call to
`org-icalendar-export-current-agenda' does not complete within
several minutes, during which time I see 100% CPU usage and rapid
memory usage growth.
So it looks to me like maybe some part of the export process uses
exponentially more time and memory, depending on the input, since a
minimal test case does not produce the problem.
What's the next step for debugging this? Please let me know if I can
provide more information.
Thanks!
--
Best,
Richard
next reply other threads:[~2014-08-26 17:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 17:40 Richard Lawrence [this message]
2014-08-26 18:10 ` Bug?/performance issue in org-icalendar-export-current-agenda OSiUX
2014-08-26 19:16 ` Nicolas Goaziou
2014-08-26 19:59 ` Richard Lawrence
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871ts3du98.fsf@berkeley.edu \
--to=richard.lawrence@berkeley.edu \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.