From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH v2 00/16] Speeding up DEFVAR_PER_BUFFER Date: Sun, 22 Nov 2020 15:11:22 -0500 Message-ID: References: <20201119153814.17541-1-sbaugh@catern.com> <837dqdxtea.fsf@gnu.org> <87a6v9jqz8.fsf@catern.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11911"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , dgutov@yandex.ru, arnold@tdrhq.com, Richard Stallman , emacs-devel@gnu.org To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 22 21:12:00 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kgviK-0002zY-6s for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Nov 2020 21:12:00 +0100 Original-Received: from localhost ([::1]:42826 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgviJ-0003X9-9e for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Nov 2020 15:11:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42276) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgvho-00036g-63 for emacs-devel@gnu.org; Sun, 22 Nov 2020 15:11:28 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:32476) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgvhm-0006LC-PE; Sun, 22 Nov 2020 15:11:27 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 40DBC80EDA; Sun, 22 Nov 2020 15:11:25 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B6F2580AF9; Sun, 22 Nov 2020 15:11:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1606075883; bh=p/O50Wd5/s9545JOqJN1X2NuLTrNzUiq7CwzU3U/Chk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=V/TsFTXDIAtou0jwF82+x+GZurzHK20J9Ue9ZLGramrLUmYG8RGelvCsQi9Ac9xJI qKiizI+8pQC+BBSKrbTmtHxsxBrNIWteX3hD5lGshxl0zhSPDKwMh+BjuiTD3HcUse KadT3pPBiXUXCSYHYNliETeOSvXzB3i9zKrS+L3Yc9Yv/bCEeLsCY8qK1HxwT7mw+0 FDJ4v5Rg5JNb54USpeDtuEtiRMlkuRe8tdWKa5/dKK5XnAGYDJ50A/HRpfRru2nlFc ddTXyEWQcT4kS7w0EXlHphPK/8YqUNNrFpJsI3UzSz5avjPGm8XSpCSQGoag3P2yGj kt2XbyT2pzvkg== Original-Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 679A8120206; Sun, 22 Nov 2020 15:11:23 -0500 (EST) In-Reply-To: <87a6v9jqz8.fsf@catern.com> (Spencer Baugh's message of "Sun, 22 Nov 2020 11:28:27 -0500") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:259649 Archived-At: > Ah, no, I mean benchmarking the rest of Emacs to see the impact. I've > already benchmarked these changes on the case they're intended to fix. There's the `elisp-benchmark` suite in GNU ELPA, but that tests the execution time to run ELisp code, which I can't imagine can be significantly affected by your patch. The other parts that could be affected could be the time for redisplay or some other primitives that repeatedly look at things like `BVAR (current_buffer, enable_multibyte_characters)`. Tho, if you patch is careful not to do the "check for `Qunbound`" for those vars whose buffer_local_flag said -1 (like `enable_multibyte_characters`), then the risk is even lower. Stefan