From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Prickliness of the "invalid byte code" stuff Date: Tue, 18 Jun 2019 15:48:30 -0400 Message-ID: References: <87tvcq9b0w.fsf@igel.home> <83v9x2svmf.fsf@gnu.org> <83fto6sphn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="186097"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: eggert@cs.ucla.edu, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 18 21:49:12 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.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hdK6S-000mI0-7K for ged-emacs-devel@m.gmane.org; Tue, 18 Jun 2019 21:49:12 +0200 Original-Received: from localhost ([::1]:33132 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hdK6R-0006X5-9S for ged-emacs-devel@m.gmane.org; Tue, 18 Jun 2019 15:49:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46501) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hdK6I-0006Wz-9o for emacs-devel@gnu.org; Tue, 18 Jun 2019 15:49:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hdK68-0000QP-UF for emacs-devel@gnu.org; Tue, 18 Jun 2019 15:48:57 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41773) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hdK5u-0000D8-SW; Tue, 18 Jun 2019 15:48:39 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C985881171; Tue, 18 Jun 2019 15:48:36 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 006EC80748; Tue, 18 Jun 2019 15:48:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1560887315; bh=NzkdYzEeb48zn7XI4h4P1icLhTihAFz0YAdVBpwpKgA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=GIzsbW3f0W/JgnbqkrZUICuzSBj+pJmyxnYE+g0MsyduImY1qmz5HMMugPDmPA9J0 Zys8mMrLjg2G6th7gxQtyNo8n9J6ZuWfxuA211niWpUiiREggJWLiKnXYjUeaiB11M OSpsKPUdz/8FhVzxeliZTkDJYamZs720QQQ7l4KClz6GpLXu3+7Z/9WRKvQHbaM7gz H850FWG6bElK2aLgKrMnvGDeyMLoROsrPQ/XhV4OolWrVPLLUpeB1XI+H4vl07Ha85 aN5iJH31okaNzrYchkbfUarN3A0+iqnuuhsJkqYOo7FW1DRQ42QWQTO3Md52Q04wSB VQNDmqRp/eFhQ== Original-Received: from alfajor (unknown [157.52.10.58]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5CA28120BB3; Tue, 18 Jun 2019 15:48:34 -0400 (EDT) In-Reply-To: <83fto6sphn.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 18 Jun 2019 21:44:04 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:237867 Archived-At: >> The files using this option are expected to be faster to load (because >> we load a bit less into heap). > There's also the effect on Emacs memory footprint, right? Yes. >> The downsides are: >> - it doesn't work when the .elc files are compressed. >> - it doesn't work when the .elc files are loaded via Tramp. >> - If the .elc files is re-generated after the .elc file was loaded, >> calling functions from that file typically signal an error (such as >> "invalid byte code"). > The same problems happen with lazily loading doc strings, right? Yes (at least for the third point (reload), not sure how the first two points are affected by compression and access via Tramp). > Or is that different in some way? There are some qualitative differences: - docstrings are only loaded in fairly specific circumstances (mostly C-h ), whereas lazy loading of code can happen in the middle of arbitrary code execution, so an error there can be more troublesome. - when lazy loading a docstring and we discover that the file has changed (which we admittedly don't always notice), the code currently is able to reload the .elc file to update the offset and try again. In contrast, for lazy loading of code, the code is currently unable to do that (this is the origin on this discussion: it could be fixed in the common cases, but last I looked at it, it'd require changes to the code which could be detrimental to the common case). - when we don't notice that the file was modified (i.e. the offset is wrong, but it happens to point to a valid place), displaying the wrong docstring is just annoying, whereas loading the wrong bytecode can lead to much more severe problems. >> A `grep byte-compile-dynamic: **/*.el` seems to indicate it's currently >> used in 12 files bundled with Emacs. > Any idea why those 12 use it? I think in the 20th century, the performance difference could be measured (at least in benchmarks, tho maybe also in actual use), but I seriously doubt it makes a noticeable difference on machines of this century (not sure if it's because of changes in hardware such as available RAM or CPU speed, or because the growth of the rest of Emacs dwarfs those effects, or what). Stefan