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
