From: "Björn Lindqvist" <bjourne@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Bloat in the Emacs Windows package
Date: Wed, 17 Apr 2019 17:07:23 +0200 [thread overview]
Message-ID: <CALG+76dRyKdfph-M4oRVwJQh2RzvzkjqMdaO4LB-4poyP5tjCA@mail.gmail.com> (raw)
In-Reply-To: <A827EB53-EE8F-41B2-933B-689268DE1BAD@gnu.org>
Den ons 17 apr. 2019 kl 09:31 skrev Eli Zaretskii <eliz@gnu.org>:
>
> On April 17, 2019 8:01:56 AM GMT+03:00, "Björn Lindqvist" <bjourne@gmail.com> 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
next prev parent reply other threads:[~2019-04-17 15:07 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-17 5:01 Bloat in the Emacs Windows package Björn Lindqvist
2019-04-17 7:31 ` Eli Zaretskii
2019-04-17 11:15 ` Van L
2019-04-17 11:26 ` Eli Zaretskii
2019-04-17 12:39 ` Stefan Monnier
2019-04-17 14:49 ` Eli Zaretskii
2019-04-17 16:17 ` Eli Zaretskii
2019-04-18 22:02 ` Björn Lindqvist
2019-04-19 7:00 ` Eli Zaretskii
2019-04-17 17:26 ` Phillip Lord
2019-04-17 17:55 ` Stefan Monnier
2019-04-19 0:02 ` Björn Lindqvist
2019-04-19 7:33 ` Eli Zaretskii
2019-04-19 13:23 ` Óscar Fuentes
2019-04-22 21:04 ` Phillip Lord
2019-04-22 21:41 ` Óscar Fuentes
2019-04-17 13:42 ` Stefan Monnier
2019-04-17 16:19 ` Óscar Fuentes
2019-04-17 17:28 ` Phillip Lord
2019-04-17 15:07 ` Björn Lindqvist [this message]
2019-04-17 16:32 ` Eli Zaretskii
2019-04-18 23:44 ` Björn Lindqvist
2019-04-19 7:27 ` Eli Zaretskii
2019-04-19 14:17 ` Óscar Fuentes
2019-04-19 15:05 ` Eli Zaretskii
2019-04-22 20:55 ` Phillip Lord
2019-04-17 17:39 ` Phillip Lord
2019-04-17 18:06 ` Stefan Monnier
2019-04-17 18:32 ` Eli Zaretskii
2019-04-18 16:05 ` Phillip Lord
2019-04-18 19:08 ` Eli Zaretskii
2019-04-18 21:19 ` Phillip Lord
2019-04-18 23:12 ` Óscar Fuentes
2019-04-19 6:29 ` Eli Zaretskii
2019-04-22 20:40 ` Phillip Lord
2019-04-23 2:25 ` Stefan Monnier
2019-04-23 10:01 ` Phillip Lord
2019-04-23 11:28 ` Robert Pluim
2019-04-23 21:49 ` Phillip Lord
2019-04-26 16:30 ` Phillip Lord
2019-04-26 17:04 ` Óscar Fuentes
2019-04-26 21:41 ` Phillip Lord
2019-04-27 18:12 ` Björn Lindqvist
2019-04-27 18:17 ` Phillip Lord
2019-05-03 1:06 ` Björn Lindqvist
2019-05-03 6:49 ` Eli Zaretskii
2019-05-03 18:38 ` Björn Lindqvist
2019-05-03 18:42 ` Eli Zaretskii
2019-05-03 20:20 ` Stefan Monnier
2019-04-23 5:37 ` Eli Zaretskii
2019-04-17 15:44 ` Phillip Lord
2019-04-17 16:25 ` Óscar Fuentes
2019-04-17 16:46 ` Eli Zaretskii
2019-04-18 16:00 ` Phillip Lord
2019-04-18 15:56 ` Phillip Lord
2019-04-18 16:39 ` Óscar Fuentes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALG+76dRyKdfph-M4oRVwJQh2RzvzkjqMdaO4LB-4poyP5tjCA@mail.gmail.com \
--to=bjourne@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).