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: Fri, 19 Apr 2019 10:27:30 +0300 Message-ID: <83k1fqcv4t.fsf@gnu.org> References: <83a7gofv94.fsf@gnu.org> 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="136013"; 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 Fri Apr 19 09:33:02 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 1hHO18-000ZFM-3A for ged-emacs-devel@m.gmane.org; Fri, 19 Apr 2019 09:33:02 +0200 Original-Received: from localhost ([127.0.0.1]:52690 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHO17-0008DG-2I for ged-emacs-devel@m.gmane.org; Fri, 19 Apr 2019 03:33:01 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49893) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHO01-000883-GF for emacs-devel@gnu.org; Fri, 19 Apr 2019 03:31:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46163) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHNw5-0002ni-NX; Fri, 19 Apr 2019 03:27:49 -0400 Original-Received: from [176.228.60.248] (port=2153 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hHNw4-0007jx-4s; Fri, 19 Apr 2019 03:27:49 -0400 In-reply-to: (message from =?utf-8?Q?Bj=C3=B6rn?= Lindqvist on Fri, 19 Apr 2019 01:44:09 +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:235644 Archived-At: > From: Björn Lindqvist > Date: Fri, 19 Apr 2019 01:44:09 +0200 > Cc: emacs-devel@gnu.org > > > > 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? The answer depends on what you intend to do with Emacs. No one can know that in advance. Emacs on Windows is built in a way that not having some dependency available at run time is not fatal, it just means that the respective features will be unavailable, and will trigger error messages when invoked. So you can selectively delete the features you don't need, or start with none and selectively install those you do need. However, many people don't want to go through this non-trivial procedure of finding the optional packages which are compatible with the Emacs binary you have (there's the 32-bit vs 64-bit issue, and then there are different versions of each optional package), and there was a popular demand for a single large installation with all the dependencies guaranteed to work. So that's what Phillip does. IOW, the current arrangement more or less reflects what people asked us. Your needs seem to be special, but then why not install the MSYS/MinGW development environment and build your own Emacs as you see fit, installing the optional support packages that you think you will need? It isn't hard, and the detailed instructions are in nt/INSTALL.W64 (assuming you want to build with MinGW64). > 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. GNU/Linux distros have a tool to manage installed packages. We don't. GNU/Linux distros are separate operations dedicated to distributing packages in coherent ways, something we aren't and can never be. If you want to install Emacs that way, I suggest to explore the MSYS2 project, perhaps it has Emacs packaged more to your liking. This here is the upstream Emacs project, and providing a binary package for Windows is already much more than we do for other platforms. We generally produce only the sources. > > > > 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. No, it isn't. The unexec machinery is platform specific. Emacs 27 moves to portable dumping, which will allow us to remove that array. That makes an unstripped emacs.exe about 85MB on my system, down to just 8.5MB when stripped. The price is an additional 9.5MB dump file that needs to be around when Emacs starts, for the grand total of 18MB. > > 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 > "" parameters and some missing stack frames. I.e the > worst of both worlds; neither full optimizations nor full debugging > symbols. That is true, but recent versions of GCC and GDB are much better in these circumstances, and still manage to produce useful information in optimized builds. It is admittedly less informative than in unoptimized builds, but it is _much_ better than no information at all, because at least most of the functions in a backtrace are shown with their names, not as "??". > 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. Feel free to benchmark Emacs and present the results. My (years-old) benchmarks told a different story, but maybe things have changed with the newer GCC versions. Most GNU project stil ship Makefile's that use -O2 in production builds, so Emacs is not alone in this, definitely not on Windows. > > And I don't think Phillip uses -fomit-frame-pointer, because it's a > > net loss. > > Why? Because the backtraces are much less informative, and because modern 64-bit processors have enough registers even without having one more. > > 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. We have the no-deps package for people whose disk space is at premium. And anyway, are you saying that a 100MB file doesn't fit on a typical disk of a Windows 9X system? There's a limit to exaggeration when you want to make a point; if you exceed that limit, your arguments run the risk that people will not regard them as serious.