From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: igc, macOS avoiding signals Date: Sat, 04 Jan 2025 09:02:20 +0100 Message-ID: References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <87msgdkt29.fsf@gmail.com> <86h66lnjrt.fsf@gnu.org> <868qrxnfrw.fsf@gnu.org> <87a5ccl2zx.fsf@gmail.com> <875xn0p3l1.fsf@protonmail.com> <86ldvwm190.fsf@gnu.org> <87cyh8nczh.fsf@protonmail.com> <867c7fncom.fsf@gnu.org> <87pll3ivzs.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38654"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , Pip Cet , spd@toadstyle.org, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 04 09:04:15 2025 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 1tTz8p-0009ux-6e for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Jan 2025 09:04:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTz7Q-00056y-KW; Sat, 04 Jan 2025 03:02:48 -0500 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 1tTz77-0004J3-13 for emacs-devel@gnu.org; Sat, 04 Jan 2025 03:02:30 -0500 Original-Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tTz75-0006me-C3; Sat, 04 Jan 2025 03:02:28 -0500 Original-Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-43618283d48so93182715e9.1; Sat, 04 Jan 2025 00:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735977744; x=1736582544; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Sw6v2cPg6VBSVB85mQGZWyhN9CZzkJb/QIlCMRYV2Gc=; b=awDLumGWAITODJ2ASCG2fIQAbSrAG/+GaEcLzA7+IM7ofK4fULDbXNsDSDvPvVQrpO 8Iunh9qHae8HiFvMTzUsgszfup6ay8OlAQ9m6TJYc2h/UNMg1gnB1sMS0cU73t4vVKa5 Sjn7tfPHP1UlnhQILPwpPhN8iHbjaPvSdC1/MIIVx6wM1zvTlONDOauTyy/wujA9cI7i WMHs0MLQH/PjhqpO0dWSyVOVE/7h9qGxGeX++KSchp1arnzuiY2Ts1BaFNSMgpnNYUsV bY0AIJFiFAU4WsZ7qBSG3LQ+Xm6FECMfpPK9OQbpsoWozJppUYT8tOUDeoc4sJaikipd KeyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735977744; x=1736582544; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Sw6v2cPg6VBSVB85mQGZWyhN9CZzkJb/QIlCMRYV2Gc=; b=QFo7PdZHrJ1R6ep22UGwHdWUn/vnNLia0wphnsyiNa4Jgt8g10WFRL8VxNp6SnmMvw PMm6z6IGV9PKRlf5mA9wZpmIYH4C/oPivB3v0gmC86tRDjJndc8p6ADmrwKqb36U6Wtf rfCz0k6WvGMTEjlADmvWnnYpCrS858eqAvzQBiM4GJppZf/l2DCxq2cGiJf3jdtmcKC4 H9YgLmuHAIlC3+6xcs6FZTw1a3bSUwyD9xgRqnVcyOQElfLdQv5mV14ByKiEv7D4Wjks IpbkXkQapUOPd6Fg1YPP/8A09p0M138hR/BSIEmvySpuZycoQVFoipQ6eBQ7ho+hpv11 cNiQ== X-Forwarded-Encrypted: i=1; AJvYcCVNHq45biAbxxkIWyKBcgfsUAitK7Mofy9/q7ap05DoqDnDtcNDKQ/BI2m/1mzX0RhQU7rFKF6hEHbS8A==@gnu.org X-Gm-Message-State: AOJu0YwGyvqi3St5tAgCKxibhiYWUNpbEeSCmcmB58vDYGz84i34wc02 k727f6vMmQexlW7OWhas9tNekgWcr3bqm2s48S/BvYMRv6D9xQLRaxH6Uw== X-Gm-Gg: ASbGnculkKwJdKCxPc5I5gkG23YqpGvir4c1BqmkQ+oQI7qKlUADKQBLcJR4tNqvtKw c83fVm7yNuNvkZjibQkS1wg7+zlmpqXyRdi0UQQTksBSlJ7JkrKEX1+Fa9qTCvWOvasWw6N0PIi Z3D5Zt8G8RyWhFk+4edMeRBOpKXEhkJAnufYK9pYOKNm88Kq6ZKVYxNal69XL4Va2QMyPNOtGFz JfvROG67NvN62SzOjHbHRLcpbagY084O7m26JX8MADS1ibiAXTZk04d04s64POOQBKoMDnbWNKc 3bLX+v/QrXtdSF56ultwjac6XAbzw4RJHEkKbjX/TKUlKobQfvfLW3k9d+VJSLEsFA== X-Google-Smtp-Source: AGHT+IFlc1x8sn+goPePghdaS0Ep2zNpGobxU+ux4z8Z9g+NCHssbs8j3giPbzm8e4QzYqI+5koADQ== X-Received: by 2002:a05:600c:3150:b0:434:f1e9:afae with SMTP id 5b1f17b1804b1-43668547374mr341728985e9.1.1735977744235; Sat, 04 Jan 2025 00:02:24 -0800 (PST) Original-Received: from pro2 (p200300e0b73c9f00c50ae305bf989514.dip0.t-ipconnect.de. [2003:e0:b73c:9f00:c50a:e305:bf98:9514]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c828e3fsm43085639f8f.5.2025.01.04.00.02.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jan 2025 00:02:23 -0800 (PST) In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?= =?utf-8?Q?s?= message of "Sat, 04 Jan 2025 08:01:13 +0100") Received-SPF: pass client-ip=2a00:1450:4864:20::333; envelope-from=gerd.moellmann@gmail.com; helo=mail-wm1-x333.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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.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:327654 Archived-At: Gerd M=C3=B6llmann writes: > Helmut Eller writes: > >> On Tue, Dec 31 2024, Eli Zaretskii wrote: >>> We'd need to add a new function to process_pending_signals, which >>> would process SIGPROF and maybe also SIGALRM. The signal handlers for >>> those would then only set a flag (not pending_signals, some other >>> flag). >> >> I implemented this with the two attached patches. The trouble is that, >> the recorded backtraces are not same. This can be seen by looking at >> the call tree produced by profiler.el and the attached profiler-test.el. >> When add_sample is called in the signal handler, then the call tree for >> the foo example looks so: >> >> ... >> 1986 100% main >> 1986 100% record-samples >> 1986 100% foo >> 1074 54% float-time >> 0 0% ... >> >> When add_sample is called from process_pending_signals, it looks like >> this: >> >> ... >> 1986 100% main >> 1986 100% record-samples >> 1986 100% foo >> 0 0% ... >> >> Not the absence of float-time. The reason for this is, that in >> bytecode.c, maybe_quit is called before the function is pushed to the >> backtrace with record_in_backtrace. In the second patch, I moved this >> call forward to before the function is popped with lisp_eval_depth--. >> With this patch, the call tree includes float-time again: >> >> ... >> 1989 100% main >> 1989 100% record-samples >> 1989 100% foo >> 1981 99% float-time >> 0 0% ... >> >> However, float-time has now 99% as opposed to 54% in the first call >> tree. >> >> A more complex pair of call trees is attached in the files >> bar-0.report and bar-2.report. A significant difference there is >> in this section: >> >> ... >> 781 73% animate-place-char >> 19 1% delete-char >> 16 1% floor >> 4 0% undo-auto--undoable-change >> 4 0% undo-auto--boundary-ensure-timer >> 96 9% insert-char >> 14 1% undo-auto--undoable-change >> 6 0% undo-auto--boundary-ensure-timer >> 5 0% beginning-of-line >> 232 21% move-to-column >> ... >> >> compared to the version with both patches applied: >> >> ... >> 693 72% animate-place-char >> 32 3% delete-char >> 29 3% window-start >> 43 4% insert-char >> 309 32% move-to-column >> 222 23% beginning-of-line >> 8 0% undo-auto--undoable-change >> 8 0% undo-auto--boundary-ensure-timer >> 8 0% run-at-time >> 8 0% timer-set-function >> 8 0% timerp >> 8 0% vectorp >> ... >> >> E.g. the percentage attributed to beginning-of-line is quite different >> in those two versions (23% and 0%). >> >> I'm not sure if those differences are acceptable. I also have no good >> idea how to reduce it, except inserting more calls to maybe_quit. >> >> (In eval_sub and Ffuncall, it would also help the profiler to move the >> maybe_quit call forward before lisp_eval_depth--. This would only matter >> for interpreted functions, not in byte compiled code. Curiously, >> apply_lambda doesn't call maybe_quit at all.) >> >> Helmut > > Doesn't matter much at this point, probably, but I'm feeling a bit > uneasy about the pending_profiler_signals count. > > Say we get two SIGPROFs that we can't record samples for, for some > reason. The signals occur at times t0 and t1. We then add_sample(2) at > t2 > t1 with the assumption that sample(t1) is close to sample(t2) so to > speak, which I find okay if t2 is close enough to t1. > > When we use a count of 2 though, we kind of also assumes that sample(t0) > is close to samole(t1). > > Is that okay? Not sure. Another thought that crossed my mind. Not that I have an idea how to use that, but maybe someone else has? With the existing arrangement, a count in the profiler log means time. It's count * sampling-interval since SIGPROFs arrive in fixed intervals, ignoring details. With the new arrangement, the intervals between samples are generally not fixed length. Sampling is done when we get to it. Of course when we get to it often enough, we are approximating fixed intervals, but in general a count doesn't necessarily measure time, or only to a degree. Can we use that somehow?