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,