Re: Making 'eq' == 'eql' in bignum branch

[Eli Zaretskii <eliz@gnu.org>]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 31 Jul 2018 15:44:24 -0700
> 
> > One way of estimating what happens in the majority of uses is to find
> > Emacs APIs other than numerical calculations that can return floats,
> > and try to analyze what kind of floats will be the result.  Like
> > file-system-info and file-attributes, for example.
> 
> These should be fine on a 64-bit platform. file-system-info invariably 
> yields floating-point numbers with the bottom three bits zero, due to 
> how modern file systems are built (their sizes are multiples of powers 
> of two). file-attributes returns an exact value unless your file is 
> larger than 2**61 bytes (2 EiB), and once we get to the rare files 
> larger than that we should be using bignums anyway. (The same could be 
> said for file-system-info, of course.)

OK, but those were just examples, I didn't do an exhaustive search for
such APIs.  Are there any others?

Then there are FP calculations in Lisp, e.g. in line-move-partial.
This gets executed many times in any Emacs, and I presume the values
there can be any FP number, so it's more akin to the use case of FP
programs we agreed not to consider.  Searching for 'float', 'round',
and 'floor' through the lisp/ directory brings more than 2000 hits,
quite a few in Calc, but many unrelated to Calc.  For example,
window.el seems to have many hits, as well as CC Mode, Org, and
calendar-related functions.  Also image.el, Gnus, and timer.el.

> > How faster, in absolute numbers and in percents, will your build
> > finish with the proposed changes?
> 
> I won't know unless I take the time to code it up.

OK, but do you have an estimate?  If not, how do you know it will be
faster?