Nicolas Goaziou writes:
> Kyle Meyer writes:
>
>> Nicolas Goaziou writes:
>>
>>> If there is no more feedback nor objection, I'll merge the branch in
>>> master before the end of the week.
>>
>> One issue I noticed: The sorting of categories defined in
>> org-agenda-sorting-strategy is not hono
bugs:
the following line will produce an entry in the agenda.
# S CHEDULED: <%%(memq (calendar-day-of-week date) '(1 2 3 4 5))>
and tel: links are interpreted as timestamps.
and the closing time for clocks are not listed.
and it misses an entire, normal looking inactive timestamp that is the
On 10/3/17, Nicolas Goaziou wrote:
>> org-element-at-point 1104
>> 17.213785437 0.0155921969
>> org-element--parse-to 1104
>> 17.098407592 0.0154876880
>> org-element--current-element 69978
>> 15.421312201
>> The overall outcome (from elp) was:
>>
>> | wip-agenda-speedup | 823.31343007 |
>> | master | 13.70077639 |
>
> Fixed.
Thanks! Looks much better now.
> Could you test it again?
Now the numbers (for the agenda today [2017-10-03 Tue 12:19]) are
| wip-agenda-speedup | 40.3 |
| ma
Hello,
Samuel Wales writes:
> fr: org-git-version to show branch name.
>
> On 10/2/17, Nicolas Goaziou wrote:
>> Do you mean you get an error which was fixed earlier? What error?
>
> you fixed error.
>
>>> ... but 9maint and 9master produce agenda in about 3s ...
>>>
>>> ... while wip produces
Hello,
Marco Wahl writes:
> The overall outcome (from elp) was:
>
> | wip-agenda-speedup | 823.31343007 |
> | master | 13.70077639 |
Fixed. Could you test it again?
Thank you.
Regards,
--
Nicolas Goaziou
fr: org-git-version to show branch name.
On 10/2/17, Nicolas Goaziou wrote:
> Do you mean you get an error which was fixed earlier? What error?
you fixed error.
>> ... but 9maint and 9master produce agenda in about 3s ...
>>
>> ... while wip produces agenda in 26.75s ...
>
> This is obviously a
Hi,
Here is my contribution to the testing.
I used my personal setting. I started a fresh Emacs and executed the
block
#+begin_src emacs-lisp :results drawer
(elp-instrument-package "org-")
(org-agenda-list)
(elp-results)
(set-buffer "*ELP Profiling Results*")
(buffer-string)
#+end_src
With br
Hello,
Samuel Wales writes:
> ... and i am getting a fixed error from before ...
Do you mean you get an error which was fixed earlier? What error?
> ... but 9maint and 9master produce agenda in about 3s ...
>
> ... while wip produces agenda in 26.75s ...
This is obviously a bug. I would need
Hello,
Matt Lundin writes:
> Nicolas Goaziou writes:
>
>> Some feedback about the new agenda speed would be nice.
>
> One small bug I found with wip speedup branch. When trying to reschedule
> in the agenda with org-agenda-do-date-later or
> org-agenda-do-date-earlier, org mode gives a message:
Hello,
Kyle Meyer writes:
> Nicolas Goaziou writes:
>
>> If there is no more feedback nor objection, I'll merge the branch in
>> master before the end of the week.
>
> One issue I noticed: The sorting of categories defined in
> org-agenda-sorting-strategy is not honored. The default category
>
... and i am getting a fixed error from before ...
... but 9maint and 9master produce agenda in about 3s ...
... while wip produces agenda in 26.75s ...
for my 2d agenda. elp as instructed shows no significant differences
org-agenda-prepare-buffers1
1.221983848 1.
Nicolas Goaziou writes:
> Some feedback about the new agenda speed would be nice.
One small bug I found with wip speedup branch. When trying to reschedule
in the agenda with org-agenda-do-date-later or
org-agenda-do-date-earlier, org mode gives a message:
"Cannot find time stamp"
Best,
Mat
Nicolas Goaziou writes:
> Matt Lundin writes:
>
>> I am finding that the branch is still much slower than the current
>> master even when no agenda files have changed (i.e., when running
>> org-agenda-redo in an existing agenda buffer without changing
>> anything).
>
> This is interesting. Could
Hello,
Samuel Wales writes:
> i am getting errors. in particular, it crashes when it is looking for
> log entries in a task that does not have log entries. there is no
> rhyme or reason and i have no mce. i remove teh task and another task
> produces teh error.
What is a "crash"? If Emacs cr
maybe it is trying to parse a link that looks like a log entry?
On 10/1/17, Samuel Wales wrote:
> my use is similar to matt's in that i use a 2d view.
>
> i am getting errors. in particular, it crashes when it is looking for
> log entries in a task that does not have log entries. there is no
>
my use is similar to matt's in that i use a 2d view.
i am getting errors. in particular, it crashes when it is looking for
log entries in a task that does not have log entries. there is no
rhyme or reason and i have no mce. i remove teh task and another task
produces teh error.
not ready fro p
Matt Lundin writes:
> I am finding that the branch is still much slower than the current
> master even when no agenda files have changed (i.e., when running
> org-agenda-redo in an existing agenda buffer without changing
> anything).
This is interesting. Could you provide a report of the second
Hello,
Matt Lundin writes:
> I think I have a fairly standard setup (some customizations, additional
> features such as habits). I'll do some testing with minimal examples to
> see if I can find out why the new branch is so much slower in my case.
Are 1.4 s "so much slower" than of 1 s. Granted
Matt Lundin writes:
>
> Here is a quick comparison of the top elp-results using a couple of commands:
I'm including the full elp results for reference. These were run with my
org agenda files and with customizations that I don't have time to
isolate at the moment. I'll try to provide a report wit
Nicolas Goaziou writes:
> Hello,
>
> Samuel Wales writes:
>
>> have not beena ble to respons for health reasons. i have rsposne
>> partly done. i think result is slightly slower but seems tob e
>> correct if you count recent maint as correct.
>
> It can be slightly slower if you start with a c
Nicolas Goaziou writes:
> If there is no more feedback nor objection, I'll merge the branch in
> master before the end of the week.
>
> Until then, the changes are still available in wip-agenda-speedup branch
> for review.
Thanks for the heads up. I just had a chance to test the
wip-agenda-speed
Hello,
Samuel Wales writes:
> have not beena ble to respons for health reasons. i have rsposne
> partly done. i think result is slightly slower but seems tob e
> correct if you count recent maint as correct.
It can be slightly slower if you start with a cold cache and never
re-use it, e.g., w
Nicolas Goaziou writes:
> If there is no more feedback nor objection, I'll merge the branch in
> master before the end of the week.
One issue I noticed: The sorting of categories defined in
org-agenda-sorting-strategy is not honored. The default category
sorting for the agenda is to order the c
have not beena ble to respons for health reasons. i have rsposne
partly done. i think result is slightly slower but seems tob e
correct if you count recent maint as correct.
Nicolas Goaziou writes:
> I rewrote the part responsible for agenda generation in "org-agenda.el".
> Basically, I refactored some hot loops and introduced a cache mechanism
> for data extracted out of agenda files.
>
> I expect to see some interesting improvements when viewing the agenda
> with a
Hello,
Samuel Wales writes:
> On 8/27/17, Nicolas Goaziou wrote:
>> I expect to see some interesting improvements when viewing the agenda
>> with a span larger than one day, or when generating an agenda view
>> without having touched most of the agenda files since last view.
>
> wow, great! i
On Wednesday, 30 Aug 2017 at 17:00, Nicolas Goaziou wrote:
> I think I spotted the problem. I updated the branch. Could you try
> again?
Done. Attached is the resulting file from elp; much much better! I
haven't rerun the default agenda as my agenda files may have changed but
only by 1-3 new ent
Eric S Fraga writes:
> Default and speedup results attached with org from a minute or so
> ago. Still quite a difference between the two and not in the desired
> direction :-( Hope these results help!
Thank you.
I think I spotted the problem. I updated the branch. Could you try
again?
Also,
Forgot to add: I re-enabled my 14 <%%()> lines for completeness.
--
: Eric S Fraga via Emacs 26.0.50, Org release_9.0.10-715-g8b5b2c
signature.asc
Description: PGP signature
On Wednesday, 30 Aug 2017 at 11:00, Nicolas Goaziou wrote:
> or by trying in a fresh Emacs session. I didn't change the cache format
> so far, though.
All tests are with fresh emacs sessions: emacs, instrument package,
agenda, view month, next month, elp results, exit emacs.
Default and speedup r
Hello,
Eric S Fraga writes:
>> I updated the "wip-agenda-speedup" branch (rebasing needed). It should
>> now call `org-agenda-skip' less often. Could you try again using that?
>
> I am not sure what "rebasing needed" means
It means that "git pull" may not be sufficient, since I overwrite
histor
I'll note that I use %%( entries for sunset/sunrise, e.g.,
%%(diary-sunrise), and for some schedules that need logic that does "shift one
day if Monday is a holiday".
That means I will need the %%( functionality to keep working. I suspect
I'm not alone. These are some fairly old and stable func
On Monday, 28 Aug 2017 at 16:24, Nicolas Goaziou wrote:
> I updated the "wip-agenda-speedup" branch (rebasing needed). It should
> now call `org-agenda-skip' less often. Could you try again using that?
I am not sure what "rebasing needed" means and whether I need to do
anything special. I did "gi
On Monday, 28 Aug 2017 at 16:24, Nicolas Goaziou wrote:
> How great! I managed to achieve a negative speed up.
:-)
Happens to me more often than I wish to admit to...
>> I had to remove a bunch of <%% (...)> items in one of my agenda files as
>> these gave me error messages about the sexp.
>
> C
Hello,
Eric S Fraga writes:
> I've compared timings old with new (from git a few minutes ago) by
> starting up emacs, instrumenting package org, viewing agenda (defaults
> to 1 day), switching to month view and then moving to the following
> month:
>
> Old agenda:
>
> | org-agenda-list
> "Russell" == Russell Adams writes:
Russell> On Sun, Aug 27, 2017 at 06:16:50PM +0200, Nicolas Goaziou
Russell> wrote:
>> Hello,
>>
>> I rewrote the part responsible for agenda generation in
>> "org-agenda.el". Basically, I refactored some hot loops and
>> intro
On Sunday, 27 Aug 2017 at 18:16, Nicolas Goaziou wrote:
> Hello,
>
> I rewrote the part responsible for agenda generation in "org-agenda.el".
> Basically, I refactored some hot loops and introduced a cache mechanism
> for data extracted out of agenda files.
>
> I expect to see some interesting impr
On Sun, Aug 27, 2017 at 06:16:50PM +0200, Nicolas Goaziou wrote:
> Hello,
>
> I rewrote the part responsible for agenda generation in "org-agenda.el".
> Basically, I refactored some hot loops and introduced a cache mechanism
> for data extracted out of agenda files.
Sounds awesome.
> The only thi
On 8/27/17, Nicolas Goaziou wrote:
> I expect to see some interesting improvements when viewing the agenda
> with a span larger than one day, or when generating an agenda view
> without having touched most of the agenda files since last view.
wow, great! i have long wanted this.
> The only thin
Completing myself:
Caveat: there's an incompatible change in `org-agenda-log-mode-items'.
You need to apply a trivial change to the values:
closed -> :closed
clock -> :clock
state -> :state
Hello,
I rewrote the part responsible for agenda generation in "org-agenda.el".
Basically, I refactored some hot loops and introduced a cache mechanism
for data extracted out of agenda files.
I expect to see some interesting improvements when viewing the agenda
with a span larger than one day, or
42 matches
Mail list logo