Re: Bloat in the Emacs Windows package

[Björn Lindqvist]

Den ons 17 apr. 2019 kl 18:32 skrev Eli Zaretskii <address@hidden>:
> > > 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.

Are all those dependencies necessary? 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.

> > > 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.

> > 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.

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.

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.

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

Why? In my limited experience it enables gcc to produce significantly
better code on the register starved x86 32 bit architecture.

> > 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.

I disagree and think that both disk space and memory footprint is
important to keep small. Most gnu/linux distributors think the same
because they strip the emacs executables even though it makes it
harder to debug crashes.

> > Emacs is also supposed to be usable on old operating systems and old
> > hardware
>
> 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. Hence the claim, to me,
implies that there is an upper bound on how large the Emacs
installation can become.


--
mvh/best regards Björn Lindqvist