emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] [WIP] org-agenda.el: Make org-entries-lessp more efficient


From: Adam Spiers
Subject: Re: [PATCH] [WIP] org-agenda.el: Make org-entries-lessp more efficient
Date: Sat, 24 Oct 2020 17:10:59 +0100

On Sat, Oct 24, 2020 at 01:36:05PM +0200, Bastien wrote:
Hi Adam, this looks good to me, thanks a lot.

Thanks for the review :-)
Does "WIP" means that you want to wait for other patches to complete this one or shall I apply this one already?

The intention is for it to be a standalone patch, so I don't think there's any need to wait for other patches. The "WIP" was coming more from the fact that I haven't done extensive testing to make sure I didn't break a single one of the many sorting criteria - especially this one:

+    ('category-keep   (if (org-cmp-category a b) +1 nil)) ;; FIXME: check this

Ideally there would already be unit and/or functional tests covering agenda sorting, but I can't see any and I imagine they would be non-trivial to add (although perhaps not too difficult either). Also, the previous behaviour was to silently ignore user-defined-{up,down} if org-agenda-cmp-user-defined was not defined, but that intuitively felt wrong to me (IMHO it kind of violates the Principle of Least Surprise) so I didn't bother to preserve that behaviour. However I admit that is a pretty subjective choice, so if you think the existing behaviour should be preserved, I can tweak the code to do that. In fact, even if you agree with me that it would be better to generate an error when user-defined-{up,down} is used with org-agenda-cmp-user-defined being nil, I just noticed that it currently generates the very unhelpful error:
    org-entries-cmp-1: Symbol’s function definition is void: nil

so we would want to explicitly catch that case and generate a more helpful error message, e.g. "org-agenda-sorting-strategy contains user-defined sorting but org-agenda-cmp-user-defined is nil". BTW, as you can partially see from the below link, I did some performance profiling relating to this change and it did indeed seem to shave a few milliseconds off org-entries-lessp, although in the grand scheme of things, that didn't make as much of a dent in org-agenda's running time as I'd hoped for ;-)
    
https://gist.github.com/trishume/40bf7045a23412d4c016f5e8533437db#gistcomment-3494087



reply via email to

[Prev in Thread] Current Thread [Next in Thread]