[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bloat in the Emacs Windows package
From: |
Björn Lindqvist |
Subject: |
Re: Bloat in the Emacs Windows package |
Date: |
Wed, 17 Apr 2019 17:07:23 +0200 |
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
- Re: Bloat in the Emacs Windows package, (continued)
- Re: Bloat in the Emacs Windows package, Phillip Lord, 2019/04/17
- Re: Bloat in the Emacs Windows package, Stefan Monnier, 2019/04/17
- Re: Bloat in the Emacs Windows package, Björn Lindqvist, 2019/04/18
- Re: Bloat in the Emacs Windows package, Eli Zaretskii, 2019/04/19
- Re: Bloat in the Emacs Windows package, Óscar Fuentes, 2019/04/19
- Re: Bloat in the Emacs Windows package, Phillip Lord, 2019/04/22
- Re: Bloat in the Emacs Windows package, Óscar Fuentes, 2019/04/22
Re: Bloat in the Emacs Windows package, Stefan Monnier, 2019/04/17
Re: Bloat in the Emacs Windows package,
Björn Lindqvist <=
- Re: Bloat in the Emacs Windows package, Eli Zaretskii, 2019/04/17
- Re: Bloat in the Emacs Windows package, Björn Lindqvist, 2019/04/18
- Re: Bloat in the Emacs Windows package, Eli Zaretskii, 2019/04/19
- Re: Bloat in the Emacs Windows package, Óscar Fuentes, 2019/04/19
- Re: Bloat in the Emacs Windows package, Eli Zaretskii, 2019/04/19
- Re: Bloat in the Emacs Windows package, Phillip Lord, 2019/04/22
Re: Bloat in the Emacs Windows package, Phillip Lord, 2019/04/17
Re: Bloat in the Emacs Windows package, Stefan Monnier, 2019/04/17
Re: Bloat in the Emacs Windows package, Eli Zaretskii, 2019/04/17
Re: Bloat in the Emacs Windows package, Phillip Lord, 2019/04/18