Re: Bloat in the Emacs Windows package

[Eli Zaretskii <eliz@gnu.org>]

> From: Björn Lindqvist <bjourne@gmail.com>
> Date: Wed, 17 Apr 2019 17:07:23 +0200
> Cc: emacs-devel@gnu.org
> 
> > Some people want the binary zip to include all the optional features
> > that Emacs on Windows can support.
> 
> 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.

> Maybe the name of the
> emacs-26.1-x86_64.zip file could be changed to indicate that it is an
> "all inclusive" package? Most users are probably fine with downloading
> the smaller emacs-26.1-x86_64-no-deps.zip instead.

AFAIR, we've changed the names in the opposite direction because most
people wanted the full version.

> > 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.  We need this to be able to strip emacs.exe, something
that in previous versions required building a special binary.  The
actual footprint in memory is much smaller, between 12MB and 18MB
depending on the configuration.

You really shouldn't worry that much about disk space, the memory
footprint of a running process is a much more relevant measure of
bloat.

> Has so much new C code been added to Emacs?

See above: most of it is data, not code.  And it isn't loaded into the
running process.

> > It is a great help to have debug info when problems are reported that
> > cause crashes and cannot be easily reproduced.
> 
> I don't think I've ever had Emacs on Windows crash on me. But if it did,
> how would I get hold of the stack trace? Executables on Windows are
> mostly run by clicking on their icons and that hides the standard input
> and output.

Emacs writes the stack trace to a file, and the user manual explains
how to convert that into human-readable addresses.

> > But if Phillip can afford prodicing separate debug info file for
> > Emacs, we could have the cake and eat it, too.
> 
> Do you mean afford as in time or as in the Windows build is run on a
> rented server?

I have no idea what would that mean for Phillip, that's something he
will have to answer.  If needed, I can help by showing the commands
required to move the debug info into a separate file.

> You are right. I stripped the emacs.exe and the startup slowdown
> remains. But it could still be related to the debugging symbols if emacs
> is compiled with -Og which is customary for debug builds.

AFAIK, it was compiled with "-O2 -g3", not -Og.

> Because if you
> compile it with more optimizations (-O2 or -O3), the debugging
> symbols becomes less useful as stack frames disappear and
> -fomit-frame-pointer makes it harder for gdb to inspect the stack.

Having symbols even in an optimized build is better than not having
them.  And I don't think Phillip uses -fomit-frame-pointer, because
it's a net loss.

> Well, yes, but how many Windows users complained about the lack of
> debugging symbols in Emacs 24?

Without symbols some problems that are reported cannot be investigated
and fixed.

> I must admit I have a hard time formulating why I think avoiding
> bloat is important, it just seem self-evident.

Not disk space.  Bloat of memory footprint, yes.

> For example, Visual Studio 2017 is over 2GB and that irritates me
> because why does it need so much space for just an IDE and a
> C/C++-compiler?!

Well, shall we postpone the argument until Emacs gets anywhere near
2GB?

> Emacs is also supposed to be usable on old operating systems and old
> hardware

Which old systems are those?