Re: Bloat in the Emacs Windows package

[Eli Zaretskii]

> From: Björn Lindqvist <address@hidden>
> Date: Fri, 19 Apr 2019 01:44:09 +0200
> Cc: address@hidden
> 
> > > Fair enough. But what optional features are missing from the
> > > -no-deps.zip file?
> >
> > All of them.  Image support beyond XPM, SSL/TLS connections, HTML and
> > XML parsing, built-in decompression, built-in JSON support.
> 
> Are all those dependencies necessary?

The answer depends on what you intend to do with Emacs.  No one can
know that in advance.  Emacs on Windows is built in a way that not
having some dependency available at run time is not fatal, it just
means that the respective features will be unavailable, and will
trigger error messages when invoked.  So you can selectively delete
the features you don't need, or start with none and selectively
install those you do need.  However, many people don't want to go
through this non-trivial procedure of finding the optional packages
which are compatible with the Emacs binary you have (there's the
32-bit vs 64-bit issue, and then there are different versions of each
optional package), and there was a popular demand for a single large
installation with all the dependencies guaranteed to work.  So that's
what Phillip does.

IOW, the current arrangement more or less reflects what people asked
us.  Your needs seem to be special, but then why not install the
MSYS/MinGW development environment and build your own Emacs as you see
fit, installing the optional support packages that you think you will
need?  It isn't hard, and the detailed instructions are in
nt/INSTALL.W64 (assuming you want to build with MinGW64).

> Even on gnu/linux distros (like Arch Linux, Ubuntu, ...) when you
> install Emacs it doesn't require all that. And on that OS other
> packages likely to be installed already depends on some dependencies
> (like libgdk-pixbuf2.0) so the "dependency burden" is shared among
> lots of software.

GNU/Linux distros have a tool to manage installed packages.  We don't.
GNU/Linux distros are separate operations dedicated to distributing
packages in coherent ways, something we aren't and can never be.  If
you want to install Emacs that way, I suggest to explore the MSYS2
project, perhaps it has Emacs packaged more to your liking.  This here
is the upstream Emacs project, and providing a binary package for
Windows is already much more than we do for other platforms.  We
generally produce only the sources.

> > > > Stripping emacs.exe produces a 29MB file for Emacs 26.2.
> > >
> > > But why is it four times bigger than in 24.5?
> >
> > Because the disk image includes a large array which is used only in
> > its small part.
> 
> Apparently it's the same on gnu/linux.

No, it isn't.  The unexec machinery is platform specific.  Emacs 27
moves to portable dumping, which will allow us to remove that array.
That makes an unstripped emacs.exe about 85MB on my system, down to
just 8.5MB when stripped.  The price is an additional 9.5MB dump file
that needs to be around when Emacs starts, for the grand total of
18MB.

> > Having symbols even in an optimized build is better than not having
> > them.
> 
> But my point is that you cannot optimize the build completely while
> still having usable debugging symbols. If you use -O3 then gcc's
> inlining of stack frames and other transformations make the debugging
> symbol data close to useless. Even with -O2 you get lots of
> "<optimized out>" parameters and some missing stack frames. I.e the
> worst of both worlds; neither full optimizations nor full debugging
> symbols.

That is true, but recent versions of GCC and GDB are much better in
these circumstances, and still manage to produce useful information in
optimized builds.  It is admittedly less informative than in
unoptimized builds, but it is _much_ better than no information at
all, because at least most of the functions in a backtrace are shown
with their names, not as "??".

> I dunno if it would make a difference for Emacs, but other projects
> I've benchmarked ran noticeably faster when compiled with -O3 over
> -O2. Especially CPU bound tasks like elisp compilation would perhaps
> run faster.

Feel free to benchmark Emacs and present the results.  My (years-old)
benchmarks told a different story, but maybe things have changed with
the newer GCC versions.  Most GNU project stil ship Makefile's that
use -O2 in production builds, so Emacs is not alone in this,
definitely not on Windows.

> > And I don't think Phillip uses -fomit-frame-pointer, because it's a
> > net loss.
> 
> Why?

Because the backtraces are much less informative, and because modern
64-bit processors have enough registers even without having one more.

> > Which old systems are those?
> 
> According to the GNU Emacs FAQ for MS Windows they are Windows 98 and
> Windows NT 4.0 through to Windows 8.1. It doesn't make sense claiming
> Windows 98 support without not also ensuring that the software fits on
> a hard disk a Windows 98 user would use.

We have the no-deps package for people whose disk space is at premium.
And anyway, are you saying that a 100MB file doesn't fit on a typical
disk of a Windows 9X system?  There's a limit to exaggeration when you
want to make a point; if you exceed that limit, your arguments run the
risk that people will not regard them as serious.