From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: The poor quality of Emacs's backtraces Date: Mon, 17 Jul 2023 19:02:25 +0000 Message-ID: References: <3D901B62-4826-4783-B684-968E6890E75A@gmail.com> <6CB5E709-8F5A-4015-9F2C-337A87916C66@gmail.com> <909FC7C1-5473-4746-97E4-B067E6C2B271@gmail.com> <5382C438-D871-4C79-820C-DCA17C59CBCA@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38607"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 17 21:03:59 2023 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 1qLTVn-0009nH-R1 for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Jul 2023 21:03:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qLTUQ-0002vh-5Y; Mon, 17 Jul 2023 15:02:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qLTUP-0002vN-3j for emacs-devel@gnu.org; Mon, 17 Jul 2023 15:02:33 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qLTUM-0002s4-Tk for emacs-devel@gnu.org; Mon, 17 Jul 2023 15:02:32 -0400 Original-Received: (qmail 33821 invoked by uid 3782); 17 Jul 2023 21:02:27 +0200 Original-Received: from acm.muc.de (p4fe15519.dip0.t-ipconnect.de [79.225.85.25]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 17 Jul 2023 21:02:27 +0200 Original-Received: (qmail 6760 invoked by uid 1000); 17 Jul 2023 19:02:25 -0000 Content-Disposition: inline In-Reply-To: <5382C438-D871-4C79-820C-DCA17C59CBCA@gmail.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307937 Archived-At: Hello, Mattias. On Mon, Jul 17, 2023 at 17:52:12 +0200, Mattias Engdegård wrote: > 14 juli 2023 kl. 22.51 skrev Alan Mackenzie : > > Aren't we always careful? I wasn't intending to make anything slower > > (except, marginally, the handling of errors). > Your intent is not in doubt, but the execution path is so sensitive > that seemingly minor changes often have outsized effect on performance. > (This cuts both ways: there have also been optimisation opportunities > in what appeared to be reasonably efficient code.) Well, I've committed the code (see below). Please actually measure it and point out where it is actually slow, rather than pontificating on vague abstractions. > Bug#64613 has been opened for this effort, and I intend to continue it > shortly. I'm certainly open for ideas about how to solve the problem > efficiently and effectively. > > I have working code implementing the putting of this extra > > information into backtraces. > Writing code is the easy part. What I'm wary about is rushing a > solution -- your solution -- to a problem that hasn't yet been studied > in sufficient depth, and with no regard to the costs involved: not just > performance but also the fact that other people, myself included, will > be the ones to maintain the feature for all foreseeable future. Well, that's one way of ensuring nothing will ever get done. I pushed this working code this morning to the new branch feature/named-lambdas, precisely to give people something concrete to study, to criticize, to measure, to improve upon, and possibly to reject. If you're going to reject anything, please reject the code, with good reason, not vague abstract ideas. And please don't exaggerate the "ease" with which it was written. > The problem is compounded by our current suboptimal representation of > closures: instead of the typical ⟨function, environment⟩ tuple, we > represent them as copies of the function object with closed-over > variables allocated separately and hacked into the (also copied) > constant vector. Making that copied function object even bigger is the > opposite of what we want to do. I don't agree, at least not at the moment. The function object, all three varieties, is big enough to hold all the information it needs to hold. Should it need to become marginally bigger, so be it. > There is also the question of what information should be there if any > were to be added. For example, source location could arguably be more > useful than function name. These are all things that can be changed later. The main danger is doing nothing but talk, talk, talk, .... Then the topic will die down, and come up again weeks, months in the future, possibly in a bug report, when we will talk, talk, talk, again. There is a cost to not fixing things. > But more importantly, since you said yourself that you would have been > satisfied with a backtrace that included the faulting operation, .... I think you've misunderstood me. That "faulting operation" is merely one of the things I want. I would not be satisfied by just that. The identity of the code referred to by each backtrace line is also essential. > .... and we agree that this is something we want in any case, wouldn't > it make sense to begin there? The risk is much lower and it won't > saddle us with irreversible maintenance costs. Whatever we do will involve "maintenance costs". Having coded this change, I have some good idea of where undue maintenance costs in the Lisp engine lie. I don't think they're where you might think. -- Alan Mackenzie (Nuremberg, Germany).