From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Speeding up native-comp progress Date: Sun, 16 Aug 2020 15:32:53 +0000 Message-ID: References: <20200816085043.vwju75c2ad2j2z7e@archlaptop.localdomain> <20200816144903.vdjpffdzkdipcwt7@archlaptop.localdomain> Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="395"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: emacs-devel@gnu.org To: Ethan Edwards Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 16 17:33:47 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 1k7KfK-000AYR-V9 for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Aug 2020 17:33:46 +0200 Original-Received: from localhost ([::1]:51194 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7KfK-00031C-0o for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Aug 2020 11:33:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57420) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7Kee-0002Y8-9o for emacs-devel@gnu.org; Sun, 16 Aug 2020 11:33:04 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:53705) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7Keb-0002uB-SJ for emacs-devel@gnu.org; Sun, 16 Aug 2020 11:33:04 -0400 Original-Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTP id 07GFWrOi000307; Sun, 16 Aug 2020 15:32:54 GMT In-Reply-To: <20200816144903.vdjpffdzkdipcwt7@archlaptop.localdomain> (Ethan Edwards's message of "Sun, 16 Aug 2020 10:49:03 -0400") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/16 10:06:41 X-ACL-Warn: Detected OS = ??? 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_PASS=-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:253853 Archived-At: Ethan Edwards writes: > On Sun, Aug 16, 2020 at 02:06:39PM +0000, Andrea Corallo wrote: >> Hi Ethan, >> >> thanks for the mail, is great to ear you enjoy using the branch. >> >> On my side I think precise bug reports are _extremely_ important. For >> precise I especially mean providing a clear recipe to reproduce it >> starting from scratch. Precise bug reports saves me a lot of time and >> greatly help improving the usability of the branch for all users. > Sure thing, is the bug-gnu-emacs [at] gnu.org the correct mailing list > for these? Yes M-x report-emacs-bug is the right way to go. We tipically add [feature/native-comp] in the subject to recognize these, Ex: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42761 >> >> Needless to say suggestions and/or patches are greatly appretiated too. > Great, is there a TODO file or anything like that would lead me in a > direction to start? The ./etc/TODO file is exactly the same in both > master and native-comp repo. No unfortunatelly there's no TODO. On my side I'm going to push a branch reworking the eln placement and compilation trigger mechanism. This is indirectly open the door for solving once for all the primitive functions advice issue (probably the cause of some bug still around). Other than that I've a nuimber of ideas on the performance subject but I believe the priority should definitely go on tackling and cleaning the open bugs. An help in that area can come on trying to reproduce and reduce analysing reported bug. Often a generic symptom is reported but investigation is required to find what is the original discrepancy with the vanilla implementation. This bug is good example of that: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42265 That said any input or suggestion based on the user experience or improvements (including documentation patches) is very welcome. Thanks! Andrea