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: Update 1 on Bytecode Offset tracking Date: Fri, 17 Jul 2020 12:20:06 -0400 Message-ID: References: <87a700fk3j.fsf@gmail.com> <87blkfoz9v.fsf@gmail.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="23857"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Zach Shaftel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 17 18:20:58 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 1jwT6Y-00065t-28 for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Jul 2020 18:20:58 +0200 Original-Received: from localhost ([::1]:33088 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jwT6X-0007Kp-2W for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Jul 2020 12:20:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60474) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jwT5x-0006sW-Hu for emacs-devel@gnu.org; Fri, 17 Jul 2020 12:20:21 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:2991) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jwT5v-0001av-5I for emacs-devel@gnu.org; Fri, 17 Jul 2020 12:20:20 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 787CA814CD; Fri, 17 Jul 2020 12:20:17 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 70F1580605; Fri, 17 Jul 2020 12:20:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1595002815; bh=W1nodDOhq4IxUq25TjC0meQzkI5qbiS0dUQg0G4uhqs=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=DCd0Z21XdDyG00g/pjOBMpmtVMRuEqm/mnqoiP44V8pmioJKKW0fmT0UKYUbj/Us4 5ioVCotHmQKlqC0X30pUu/k34R3RJiEWWcKyF68/RHs5dWa47UF8jmjswJDWqTLwSa D4iXaszn/NVQOItMQP/OT+2crbDJyro1ezvJovi84klfqyHaPv+xnBMUA8QRpYtuCB VALrXEopPkNcrDshe5OpUpBrLmVzHYVmMR3z3GHfJuQWDrZFBksOQ2EMEPXZgi5DnF EIg3QCrxcuoRgGOWS9jPfsNqQJOzwnB7/KwolVrvnmhE56IuBMjm7vZhyw9kQyrPGS nU2u/KHUoEQug== Original-Received: from milanesa (76-10-180-175.dsl.teksavvy.com [76.10.180.175]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 366EE1208E7; Fri, 17 Jul 2020 12:20:15 -0400 (EDT) In-Reply-To: <87blkfoz9v.fsf@gmail.com> (Zach Shaftel's message of "Thu, 16 Jul 2020 18:45:00 -0400") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/17 12:20:17 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] 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, URIBL_BLOCKED=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:253036 Archived-At: > Great! I just followed up on my copyright assignment as I still haven't > finished that process. I don't know whether this could be exempt or if > Rocky's assignment is sufficient, but hopefully I will hear back from > copyright-clerk soon. While waiting for the paperwork to go through, you can prepare the patch and we can start discussing it. > That seems to be the case. I'll keep looking to see if there's any low > hanging fruit in terms of splitting up the funcall logic without slowing > things down. More testing is necessary, but if a moderate chunk of > duplicated code is acceptable then there may not be as much work needed > on that branch as I had thought. It's a tradeoff, so it's hard to say what is acceptable without seeing the actual path along with the corresponding measurements of the performance impact. > Rough tests indicate it's about three times slower. Wow! That's a lot less than I expected. That makes it quite usable. This said, we'll probably still want to merge the feature into the C code simply to avoid the duplication (I expect that the Edebug reader has never been 100% faithful and that it has probably diverged over time). > Removing the string did improve performance, but not by as much as I > expected. The function that constructs the tree of "children" may be > slower than it needs to be, so I'll look into improving that. It may not > be necessary to create the children for vectors since they're constants > (outside of backquote, at least). I think vectors are rare enough that the performance benefit of special casing them is not worth the downside of losing source-location info when it'd be beneficial. > Yes, and it won't be easy to maintain the read locations across > macroexpansion, byte-opt and cconv. For byte-opt and cconv it's mostly a question of labour. For macros, OTOH, it's really fundamentally hard (or impossible, in general). We could/should introduce some new way to define macros which knows about "source code annotated with locations". There's a lot of work on Scheme macros we could leverage for that. Stefan