From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Elisp native profiler Date: Mon, 01 Oct 2012 12:37:24 +0200 Message-ID: <83a9w6cwbf.fsf@gnu.org> References: <83zk4egs0w.fsf@gnu.org> <83y5jygrni.fsf@gnu.org> <50620443.8050301@cs.ucla.edu> <20120926151625.229ef3cc9caf90e5098b18ef@cx4a.org> <20121001014217.03ac31a69b9b43516cb0dd61@cx4a.org> <50689C1D.8080005@cs.ucla.edu> <5068AEE2.4080004@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1349087867 3175 80.91.229.3 (1 Oct 2012 10:37:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Oct 2012 10:37:47 +0000 (UTC) Cc: tomo@cx4a.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 01 12:37:50 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 1TIdNl-0007A6-Cn for ged-emacs-devel@m.gmane.org; Mon, 01 Oct 2012 12:37:49 +0200 Original-Received: from localhost ([::1]:46776 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIdNf-0002LG-My for ged-emacs-devel@m.gmane.org; Mon, 01 Oct 2012 06:37:43 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIdNY-00027f-9o for emacs-devel@gnu.org; Mon, 01 Oct 2012 06:37:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TIdNS-0005bs-AX for emacs-devel@gnu.org; Mon, 01 Oct 2012 06:37:36 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:64172) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIdNS-0005bZ-2L for emacs-devel@gnu.org; Mon, 01 Oct 2012 06:37:30 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MB700E00MG1HL00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Mon, 01 Oct 2012 12:37:18 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MB700DEJMU5TVC0@a-mtaout22.012.net.il>; Mon, 01 Oct 2012 12:37:18 +0200 (IST) In-reply-to: <5068AEE2.4080004@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 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:153813 Archived-At: > Date: Sun, 30 Sep 2012 13:43:14 -0700 > From: Paul Eggert > Cc: Tomohiro Matsuyama , emacs-devel@gnu.org > > If the sample interval is too small, > bad things happen: Emacs goes catatonic or dumps > core or whatever. (I found this out by using a > sample interval of 1 microsecond -- silly, I know, > but I wanted to see what would happen....) That's a bug somewhere, isn't it? We already arrange for SIGPROF to be blocked while we are in the SIGPROF handler, so why would too frequent signals be a problem? Hmm... what happens when the SIGPROF handler exits, and SIGPROF is unblocked? Will the signals caught during the period it was blocked be reissued, and if so, how many times? > Whether an interval is "too small" depends on the > platform. The platforms most at risk are the older, > slower ones. Slower platforms should have their minimal supported interval in itimers be higher, no? And 'setitimer' should round up the interval to the minimal supported value, shouldn't it? > All that being said, it's no big deal. > 1 ms is fine too, I expect. Default value is just that: the default. If there are bad consequences possible when using very small sampling intervals, we should warn users about that in the doc strings, and perhaps even test the value inside profiler-start and ask for confirmation.