Hello, Eric S Fraga <esfli...@gmail.com> 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 history on this branch. > and whether I need to do anything special. At the very least, you need to make sure the cache is clean, with (clrhash org-agenda--data-cache) or by trying in a fresh Emacs session. I didn't change the cache format so far, though. > Default version: > > | org-agenda-list | 3 | 25.169072093 | 8.3896906976 | > | org-agenda-redo | 2 | 23.729199963 | 11.864599981 | > | org-let | 2 | 21.949337096 | 10.974668548 | > | org-agenda-get-day-entries | 768 | 20.485554483 | 0.0266738990 | > | org-agenda-get-scheduled | 768 | 13.140805835 | 0.0171104242 | > | org-agenda-later | 1 | 12.218471156 | 12.218471156 | > | org-agenda-view-mode-dispatch | 1 | 11.774425814 | 11.774425814 | > | org-agenda-month-view | 1 | 11.511459292 | 11.511459292 | > | org-agenda-change-time-span | 1 | 11.511454414 | 11.511454414 | > | org-agenda-prepare-buffers | 5 | 6.235086298 | 1.2470172596 | > | org-at-planning-p | 38286 | 4.9494982779 | 0.0001292769 | > | org-agenda-prepare | 3 | 4.6090207959 | 1.5363402653 | > | org-agenda | 1 | 3.444506372 | 3.444506372 | > | org-agenda-skip | 42757 | 3.0357010199 | 7.099...e-05 | > | org-agenda-get-deadlines | 768 | 2.9264708689 | 0.0038105089 | > | org-back-to-heading | 85980 | 2.7460824440 | 3.193...e-05 | > | org-agenda--timestamp-to-absolute | 57206 | 2.7053754779 | 4.729...e-05 | > | org-get-todo-state | 37819 | 2.5136005120 | 6.646...e-05 | > | org-time-string-to-absolute | 57206 | 2.2163205409 | 3.874...e-05 | > | org-agenda-get-blocks | 768 | 2.1708883639 | 0.0028266775 | > | org-inlinetask-in-task-p | 37309 | 2.0235439769 | 5.423...e-05 | > | org-get-agenda-file-buffer | 828 | 1.9225380609 | 0.0023219058 | > | org-agenda-to-appt | 2 | 1.776863076 | 0.888431538 | > > New wip-agenda-speedup version: > > | org-agenda-list | 3 | 31.765126901 | 10.588375633 | > | org-agenda-redo | 2 | 30.228140779 | 15.114070389 | > | org-let | 2 | 27.439146923 | 13.719573461 | > | org-agenda-day-entries | 706 | 25.781168166 | 0.0365172353 | > | org-agenda-later | 1 | 15.415702875 | 15.415702875 | > | org-agenda-view-mode-dispatch | 1 | 15.065425835 | 15.065425835 | > | org-agenda-month-view | 1 | 14.817610403 | 14.817610403 | > | org-agenda-change-time-span | 1 | 14.817599293 | 14.817599293 | > | org-get-todo-state | 150556 | 12.739302215 | 8.461...e-05 | > | org-back-to-heading | 162734 | 11.384205458 | 6.995...e-05 | > | org-agenda-prepare-buffers | 5 | 6.309316915 | 1.2618633830 | > | org-agenda | 1 | 4.5347066179 | 4.5347066179 | > | org-agenda-prepare | 3 | 4.526386149 | 1.508795383 | > | org-agenda--timestamp-to-absolute | 65195 | 3.6421088350 | 5.586...e-05 | > | org-agenda-to-appt | 2 | 2.78557571 | 1.392787855 | > | org-time-string-to-absolute | 65195 | 2.7304234570 | 4.188...e-05 | > | org-indent-initialize-agent | 11 | 2.5848328029 | 0.2349848002 | > | org-indent-initialize-buffer | 11 | 2.584644208 | 0.2349676552 | > | org-get-repeat | 113814 | 2.2632576760 | 1.988...e-05 | > | org-agenda--all-filtered-data | 3 | 1.997229961 | 0.6657433203 | > | org-get-agenda-file-buffer | 862 | 1.9403902009 | 0.0022510327 | > | org-end-of-subtree | 4920 | 1.7806221550 | 0.0003619150 | > | org-mode | 10 | 1.736419648 | 0.1736419648 | > | org-agenda--file-data | 60 | 1.5899973689 | 0.0264999561 | Still no luck. At least, it is obvious where the hanging fruits are. Unfortunately, I'm not sure where those numbers of `org-get-todo-state' and `org-back-to-heading' come from. For example, there are as many `org-get-todo-state' calls from "org-agenda.el" in both "master" and "wip-agenda-speedup" branches. Information is missing in your report. For example, I don't know how many times `org-agenda-skip' was called in the "wip-agenda-speedup" version. Could you try again with a fresh "wip-agenda-speedup" branch (I fixed "<%%...>" timestamps) and post a full ELP report? Thank you! Regards, -- Nicolas Goaziou 0x80A93738
