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: On elisp running native Date: Fri, 29 Nov 2019 10:30:33 -0500 Message-ID: References: <83zhgeoh0k.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="251542"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org, Andrea Corallo To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 29 16:31:24 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 1iaiEs-0013IG-KW for ged-emacs-devel@m.gmane.org; Fri, 29 Nov 2019 16:31:22 +0100 Original-Received: from localhost ([::1]:60248 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaiEq-0006sS-IY for ged-emacs-devel@m.gmane.org; Fri, 29 Nov 2019 10:31:21 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40725) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaiER-0006rk-UN for emacs-devel@gnu.org; Fri, 29 Nov 2019 10:30:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iaiEN-0007Is-Co for emacs-devel@gnu.org; Fri, 29 Nov 2019 10:30:53 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19445) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iaiEG-0006qo-GS; Fri, 29 Nov 2019 10:30:47 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 212C883708; Fri, 29 Nov 2019 10:30:42 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8A06182B98; Fri, 29 Nov 2019 10:30:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1575041440; bh=2hj++zqPO/Mm+PaWWlpVcHdZQmBUIIQwguZ22Tr4bXQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Im1s8sKQOxnf7juxZ/esc2icX5Gdg6tv2Xj0Tra98D3Ro0AqkqIH6gbd6nRl8xDOw UJAIJO9g+6J/0BMU9LQBBqky+pprPaMMWssNcmOjeTGN8rUYRegmAVlJCUpIhT2cCb uSGLJCZ8ZI060uB4+Ek92VHcB6araEZTY+P4k4UH/oxxoVAnks0F59TR5LaY1s7M5M E1tHnhCYQhhmY0DaJaVUXWq942bKneSBMwmZTSI59Bz94fbwjCz6h0rE+eyEV3lztH eflwAyaUK7pcJg5qLcvvPglsiQzvQ8Lsk56aYSsveUr3s11tnM85/kMyj/KtAeWwLa yi3cq712d2bRA== Original-Received: from alfajor (modemcable157.163-203-24.mc.videotron.ca [24.203.163.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4498A1203B5; Fri, 29 Nov 2019 10:30:40 -0500 (EST) In-Reply-To: <83zhgeoh0k.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 29 Nov 2019 17:10:19 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] 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:242879 Archived-At: >> | | byte-compiled | native-compiled | speed-up | >> |-------------+---------------+-----------------+----------| >> | interactive | 27s | 19s | 1.4x | >> | batch | 15s | 8s | 1.9x | So, there's 11s-12s of "interactive cost". >> To me makes quite sense that in interactive there's less difference >> cause of the re-display done in C anyway. I'm not sure what those 11s-12s come from, but I think it's safe to take the "1.9x" as the more relevant measure in terms of measuring the impact of native compilation on the speed of bytecomp.el. > Regardless of the speed-up due to using native code, it sounds strange > to me that byte-compiling interactively takes twice the time it takes > non-interactively. I have hard time convincing myself that redisplay > has such a profound effect on byte compilation, since byte-compiling a > file normally yields one or two lines of output, regardless of the > size of the file being compiled. I agree it's a bit surprising. Even it was running in a "large" interactive session, it could also be due to the time it takes to GC a larger heap (tho we normally GC such larger heaps proportionally less often, so that doesn't really explain it either). But since this is orthogonal to the gccemacs native compilation, maybe we should move it to a bug report where we can try and investigate it. Stefan