Re: Bloat in the Emacs Windows package

[Björn Lindqvist]

Den ons 17 apr. 2019 kl 09:31 skrev Eli Zaretskii <address@hidden>:
>
> On April 17, 2019 8:01:56 AM GMT+03:00, "Björn Lindqvist" <address@hidden> 
> wrote:
> > The emacs-26.1-x86_64.zip file is really big. It contains a lot of
> > files which I wonder why they are necessary. Some examples
> >
> >     python2.7.exe
> >     gdbus.exe
> >     libgdk_pixbuf-2.0-0.dll
> >     include/jasper/
> >     include/GL
> >     include/gnutls AND include/openssl
> >     lib/systemd
> >     sqlite3200.dll
> >     lib/pkgconfig
> >     lib/cmake
> >     share/bash-completion
> >     share/vala
> >     ...
>
> 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? GnuTLS support in eww? 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.

> > The emacs-26.1-x86_64-no-deps.zip installation is smaller, but still
> > double the size of the corresponding 24.5 installation. This seem to
> > be because all binaries now include debugging symbols. Some examples
> > of the size increases:
> >
> >     addpm.exe 577 kB => 2 282 kB
> >     ctags.exe 956 kB => 3 245 kB
> >     emacs.exe 8 989 kB => 121 740 kB
> >     emacs-24.5.exe 8 989 kB => 121 740 kB (emacs-26.1.exe)
>
> Stripping emacs.exe produces a 29MB file for Emacs 26.2.

But why is it four times bigger than in 24.5? Has so much new C code
been added to Emacs? Gcc's machine code generation certainly hasn't
gotten worse so that can't be it.

> We don't provide any shell scripts or batch files because the build on
> Posix systems doesn't.  Once again, it's hard to blame volunteers for
> using the build products as is, without adding any more work.

Sorry, I didn't mean to blame anyone! If the omission is lack of
volunteer time then I can look at the build and see if I can figure
it out. As I wrote in the other thread, I have some experience porting
Linux applications to Windows.

Perhaps I shouldn't have used "bloat" in the email subject line.

> > According to the thread on help-gnu-emacs Emacs binaries used to be
> > stripped of debugging symbols, but aren't anymore and that is what is
> > causing the size increase. I wonder if we can return that? Most
> > software ported to Windows, such as MinGW, strips debugging symbols so
> > it is customary. For most users they are useless because they don't
> > run emacs.exe in gdb.exe.
>
> 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.

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

> > On my machine it increases Emacs
> > start time by a second (although I don't know if that is caused by the
> > debugging symbols or if it is something else).
>
> It cannot be due to debug info, because that is not read when the
> program loads.

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

> > It is also
> > aesthetically displeasing -- hackers like minimalism and hate bloat.
>
> FWIW, I think you the first one to complain about this.

Well, yes, but how many Windows users complained about the lack of
debugging symbols in Emacs 24? I must admit I have a hard time
formulating why I think avoiding bloat is important, it just seem
self-evident. 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?!

Emacs is also supposed to be usable on old operating systems and old
hardware so saving disk space should be important imho.

> > And while on the subject of Windows packaging. How come there is no
> > MSI installer for Emacs? It shouldn't be to hard to put one together
> > and it would make Emacs a little easier to install for newbies.
>
> What tools to use to produce the binary distribution is entirely up to
> the person who does that.  And of course MSI is not free software.

The WiX Toolset which one can use to build MSIs is free software. I
don't know about the MSI format itself, but it would surprise me if
there are any legal hurdles since MSIs are supposed to be distributed by
ISVs.


--
mvh/best regards Björn Lindqvist