Jack Henahan writes: Apologies again, didn't update the commit hash properly. I swear this is the last one. :| > Jack Henahan writes: > > Modified patch attached to use my list mail rather than my work one. > >> To that end, I've attached a patch for review which removes >> `org-clock--oldest-date`, replacing its only use with `nil`, and >> altering the logic where it's actually used to account for this case and >> give a sensible-ish value of the year -50000 for the start time in >> `org-special-range`. Before the dawn of humanity seemed like a >> reasonable limit, but I'm taking suggestions. :D >> >> I'm not certain if this hits the "modify 15 lines" threshold since it's >> mainly deletion, but I'll start getting the paperwork in order and write >> a Changelog entry. >> >> Nicolas Goaziou writes: >> >>> Hello, >>> >>> Jack Henahan writes: >>> >>>> I've run into a performance issue in `org-clock` which I've narrowed >>>> down to being caused by the calculation in the defconst for >>>> `org-clock--oldest-date`. In particular, invoking `org-clock-in` or >>>> eagerly loading `org-clock` on init incurs a 21(!) second delay while >>>> calculating the constant. If I inline the value (`(-1034058236842 >>>> -45726)`, in my case), the delay vanishes. >>>> >>>> So, context out of the way (just in case someone else already knows an >>>> easier fix), I'd like to spend some spare cycles finding a better way to >>>> go about the functionality this is meant to provide. If I've read the >>>> source correctly, it's meant to provide a view of all the clocks by >>>> showing all clocks between some time way in the past until now. >>> >>> A correct fix would be to remove `org-clock--oldest-date', which is used >>> only in one place, and replace it with nil. Then all >>> `org-clock-special-range' callers need to be updated to handle this nil >>> start value. >>> >>> Regards,