From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Peter Newsgroups: gmane.emacs.help Subject: Upgrade Hunt - day four & final Date: Tue, 24 Oct 2023 22:26:40 +0200 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38895"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 24 22:37:07 2023 Return-path: Envelope-to: geh-help-gnu-emacs@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 1qvO9D-0009xc-Fi for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 24 Oct 2023 22:37:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qvO8Y-0003Hf-2E; Tue, 24 Oct 2023 16:36:26 -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 1qvO8V-0003HJ-Pu for help-gnu-emacs@gnu.org; Tue, 24 Oct 2023 16:36:23 -0400 Original-Received: from uucp.dinoex.org ([2a0b:f840::12]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qvO8R-000716-Vq for help-gnu-emacs@gnu.org; Tue, 24 Oct 2023 16:36:23 -0400 Original-Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]) by uucp.dinoex.org (8.17.2/8.17.2) with ESMTPS id 39OKa6fG066993 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 24 Oct 2023 22:36:07 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Original-Received: (from uucp@localhost) by uucp.dinoex.org (8.17.2/8.17.2/Submit) with UUCP id 39OKa6ID066992 for help-gnu-emacs@gnu.org; Tue, 24 Oct 2023 22:36:06 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Original-Received: from disp.intra.daemon.contact (disp-e.intra.daemon.contact [IPv6:fd00:0:0:0:0:0:0:112]) by admn.intra.daemon.contact (8.17.1/8.17.1) with ESMTPS id 39OKR1O1098444 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK) for ; Tue, 24 Oct 2023 22:27:01 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Original-Received: from disp.intra.daemon.contact (localhost [127.0.0.1]) by disp.intra.daemon.contact (8.17.1/8.17.1) with ESMTPS id 39OKQeLN039514 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 24 Oct 2023 22:26:40 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Original-Received: (from pmc@localhost) by disp.intra.daemon.contact (8.17.1/8.17.1/Submit) id 39OKQeQH039513 for help-gnu-emacs@gnu.org; Tue, 24 Oct 2023 22:26:40 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: disp.intra.daemon.contact: pmc set sender to pmc@citylink.dinoex.sub.org using -f Content-Disposition: inline X-Milter: Spamilter (Reciever: uucp.dinoex.org; Sender-ip: 0:0:2a0b:f840::; Sender-helo: uucp.dinoex.org; ) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]); Tue, 24 Oct 2023 22:36:09 +0200 (CEST) Received-SPF: pass client-ip=2a0b:f840::12; envelope-from=pmc@citylink.dinoex.sub.org; helo=uucp.dinoex.org 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: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:145380 Archived-At: The promised continuation... On saturday I again buckled up to refine my profiling and identify the cpu-hogging functions. And they came out to be help_echo_substitute_command_keys() Fwhere_is_internal() But, looking into these functions, they are just lengthy functions with lots of lispiness in them. Not easy to see a performace hog in there. So I came to the conclusion that there is no distinct performance hog to be found, but rather some other thread would frequently interrupt and slow things down in an evenly distributed way (which was also a wrong conclusion, but it led back onto the right track). So now, with all the printf inserted, lets get back to truss and see which thread does what at what place (should have done that earlier): 53999 103429: 8.661802081 0.000007980 sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) 53999 103429: 8.661850254 0.000007970 sigprocmask(SIG_BLOCK,{ SIGINT|SIGALRM },{ }) = 0 (0x0) 53999 103429: 8.661895521 0.000008179 ktimer_settime(0x3,0x1,0x8215da7c8,0x0) = 0 (0x0) 53999 103429: 8.661938691 0.000007984 sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) 53999 103429: 8.662007745 0.000011363 write(2,"PMc 1697366761485273: + parse_me"...,53) = 53 (0x35) 53999 103429: 8.662058629 0.000008297 write(2,"PMc 1697366761485330: + parse_me"...,43) = 43 (0x2b) 53999 103429: 8.662108232 0.000008263 write(2,"PMc 1697366761485380: + parse_me"...,43) = 43 (0x2b) 53999 103429: 8.662157594 0.000008250 write(2,"PMc 1697366761485429: + parse_me"...,43) = 43 (0x2b) 53999 103429: 8.662207699 0.000008283 write(2,"PMc 1697366761485479: + parse_me"...,43) = 43 (0x2b) 53999 103429: 8.662256946 0.000008279 write(2,"PMc 1697366761485528: + parse_me"...,45) = 45 (0x2d) 53999 103429: 8.662306245 0.000008248 write(2,"PMc 1697366761485578: + parse_me"...,45) = 45 (0x2d) 53999 103429: 8.662355398 0.000008292 write(2,"PMc 1697366761485627: + parse_me"...,45) = 45 (0x2d) 53999 103429: 8.662407964 0.000008268 sigprocmask(SIG_BLOCK,{ SIGINT|SIGALRM },{ }) = 0 (0x0) 53999 103429: 8.662456674 0.000011178 ktimer_settime(0x3,0x1,0x8215db608,0x0) = 0 (0x0) 53999 103429: 8.662500564 0.000008224 sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) So here is both: my printf() and the strange ktimer/sigprocmask loop, alternating. But: they happen in the SAME THREAD (column 2)!! *shock* How does it do this? How does it switch context without asking my kernel for permission first? I started lldb again, and this time it happened to work - probably things where now sanitized by sufficient calls to libc ;) And in the backtrace things became clearer - this is a weirdly fascinating construction of callbacks. In fact, the simple tasks of displaying a menu calls into parsing the keymap definitions (which can be user defined), which then calls into the appropriate Lisp stuff, and then from there are backdoors that call into the management functions (like setting timers). And then it also became obvious why it runs that ktimer thing all the time. I could see an occasional signal 23 (that is from the X server), I could see signal 14 every two seconds - that is the internal timer (and I couldn't find where these two seconds are configured, I would have liked to slow that down, but didn't find it in atimer.[ch]), but actually the signal processing goes on continuosely. And that is because gobble_input() sets pending_signals = true, so process_pending_signals() is called and sets it false again, and at the next instant gobble_input() sets it true again. Now to figure out what is called why in what sequence looked like too heavy. So I went for the quick fix - this seems to affect only GTK3, and that stuff is overcommitted anyway, so lets see how it does without: --- src/keyboard.c.orig 2023-06-22 13:49:11.000000000 +0200 +++ src/keyboard.c 2023-10-18 00:55:57.038605000 +0200 @@ -7415,7 +7415,9 @@ if (input_blocked_p ()) { +#ifndef HAVE_GTK3 pending_signals = true; +#endif break; } Works fine, no problems observed yet. I then started to complete my default.el configurations and switched between some file and the scratchbuffer hundreds of times via the menu, and, well, it works now. That's what I wanted. Concluding, I would say, emacs is very unfriendly to new users. All the heavy lifting needs to take place in the beginning, when things still work worst.