[O] `org-clock--oldest-date` performance

[Jack Henahan]

Hiya,

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.

I've read GNU Emacs bug #27706 [1] and attempted to reproduce to ensure
that it's not just the libc issue again, but none of the apparently
problematic examples cause any sort of hang.

This leads me to believe that it's the `dichotomy` algorithm getting a
bit out of control when `most-negative-fixnum` is -2^61.

Right now I'm just `el-patch`ing the defconst and
`org-clock-special-range`, but a more permanent solution would be
desirable.

I'll be looking at it this weekend to see if I can figure something out,
but I thought it likely that someone who understands `org-clock` better
than I might be able to chime in, or at least see if I'm the only one
hitting this issue.

Thanks,
==
Jack Henahan
Org mode version 9.1.6 (release_9.1.6-369-g3604f2) on macOS 10.13.2