From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Bloat in the Emacs Windows package Date: Wed, 17 Apr 2019 19:32:07 +0300 Message-ID: <83a7gofv94.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="84820"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: =?utf-8?Q?Bj=C3=B6rn?= Lindqvist Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 17 18:32:37 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGnUC-000LxM-FP for ged-emacs-devel@m.gmane.org; Wed, 17 Apr 2019 18:32:36 +0200 Original-Received: from localhost ([127.0.0.1]:56336 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGnUB-00048O-Dk for ged-emacs-devel@m.gmane.org; Wed, 17 Apr 2019 12:32:35 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGnTn-0003zA-Bi for emacs-devel@gnu.org; Wed, 17 Apr 2019 12:32:15 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44721) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGnTn-0001df-7L; Wed, 17 Apr 2019 12:32:11 -0400 Original-Received: from [176.228.60.248] (port=4856 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hGnTm-00022y-8J; Wed, 17 Apr 2019 12:32:10 -0400 In-reply-to: (message from =?utf-8?Q?Bj=C3=B6rn?= Lindqvist on Wed, 17 Apr 2019 17:07:23 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235590 Archived-At: > From: Björn Lindqvist > 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?