Re: 64 bit official Windows builds

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 12 Feb 2016 09:16:13 +0100
> 
> >> Not saying that GNU Find will be representative of what you can expect
> >> from Emacs. (GNU Find: I/O bound; Emacs: user bound.)
> >
> > Performance only matters when you do prolonged operations.  One such
> > prolonged operation in Emacs is reading a directory in Dired, in which
> > case what Emacs does is quite similar to what Find does.  For someone
> > who uses Dired extensively, the GNU Find example is not irrelevant.
> 
> Are there reports about Dired being slow on Windows 32 bits? Just
> curious.

Compared to what? a Posix host that runs 'ls' instead? you betcha!
Comparing that to a 64-bit Emacs would be a good measurement, I think.
I didn't try that.

> > Memory- and CPU-intensive operations is another matter.  But here,
> > too, I'd welcome actual measurements more than theories.  Measurements
> > can and do surprise, as is known to anyone who ever profiled a
> > real-life program.
> 
> I'm glad you think this way. So now we have agreed that the existence of
> a dramatic performance gap between 32 and 64 bits Emacs executables and
> its cause being API thunking is just a theory of yours based on limited
> evidence :-)

I actually said that already in my reply to Stefan, didn't I?

> My also (limited) evidence is that 64 bit Windows binaries can be a bit
> faster than 32 bit ones, and vice-versa. For instance: my experience
> building complex C++ code with GCC is that the 32 bit compiler runs a
> bit faster than its 64 bit version. For Emacs, I see no difference, it
> is responsive on both systems.

Responsiveness is not what is at stake here, as I already wrote.  You
need some prolonged operation, either I/O intensive or CPU- or
memory-intensive (or both).  Try repeatedly searching a regexp through
a large buffer, or run XML validation on a large XML document, or
anything similar.