From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Elisp native profiler Date: Tue, 25 Sep 2012 20:53:33 -0400 Message-ID: References: <83zk4egs0w.fsf@gnu.org> <83y5jygrni.fsf@gnu.org> <83vcf1hnih.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1348620822 17384 80.91.229.3 (26 Sep 2012 00:53:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2012 00:53:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 26 02:53:47 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TGfso-0001aN-1Y for ged-emacs-devel@m.gmane.org; Wed, 26 Sep 2012 02:53:46 +0200 Original-Received: from localhost ([::1]:37062 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGfsj-00052q-4C for ged-emacs-devel@m.gmane.org; Tue, 25 Sep 2012 20:53:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGfsg-00052a-Bn for emacs-devel@gnu.org; Tue, 25 Sep 2012 20:53:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGfsf-00058t-Ds for emacs-devel@gnu.org; Tue, 25 Sep 2012 20:53:38 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:16754) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGfsd-00058g-R3; Tue, 25 Sep 2012 20:53:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09FxLT4/2dsb2JhbABEtBGBCIIVAQEEAVYjEAs0EhQYDSSIHAW6CZBEA6MzgViDBQ X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="199982726" Original-Received: from 69-196-180-248.dsl.teksavvy.com (HELO pastel.home) ([69.196.180.248]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 25 Sep 2012 20:53:34 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 0A60B58EAB; Tue, 25 Sep 2012 20:53:33 -0400 (EDT) In-Reply-To: <83vcf1hnih.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 25 Sep 2012 22:10:30 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153547 Archived-At: >> > Shouldn't profiling use the same framework as atimers >> > and the other async events? >> We could do that, but to the extent that it is possible to do all the >> work in the signal_handler while still being safe, I think it's >> preferable. > I bet the "read input in a signal handler" started that way, too. AFAIK, the "read input in a signal handler" has been wrong/racy from the beginning. Tho, I guess at the beginning either the author didn't know it was wrong, or he figured he could avoid the known problems with it by playing with the malloc hooks. But, yes, maybe at some we'll have to do it differently. But doing it differently means: - doing potentially more work on QUIT (thus slowing down Emacs even when the profiler is not in use). - suffer from a sampling bias (only the stack traces that lead to a QUIT can be sampled). - miss some samples (because no QUIT occurred between the two signals). - running QUIT more often (to reduce the bias and try and avoid missing some samples), again slowing down Emacs even when the profiler is not in use. So I think for now I'd rather try and stick to "do it in the handler". Stefan