Jack Henahan <jhenahan@me.com> 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 <mail@nicolasgoaziou.fr> writes:
>
>> Hello,
>>
>> Jack Henahan <jhenahan@me.com> 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,