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: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns. Date: Tue, 02 Oct 2012 19:03:53 +0200 Message-ID: <83wqz8ajra.fsf@gnu.org> References: <506B1850.1070404@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1349197493 25202 80.91.229.3 (2 Oct 2012 17:04:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Oct 2012 17:04:53 +0000 (UTC) Cc: 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 Tue Oct 02 19:04:58 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 1TJ5sx-0001ps-Pa for ged-emacs-devel@m.gmane.org; Tue, 02 Oct 2012 19:03:55 +0200 Original-Received: from localhost ([::1]:45759 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJ5ss-0005OI-4s for ged-emacs-devel@m.gmane.org; Tue, 02 Oct 2012 13:03:50 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJ5sp-0005NG-Fp for emacs-devel@gnu.org; Tue, 02 Oct 2012 13:03:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJ5so-00075p-4k for emacs-devel@gnu.org; Tue, 02 Oct 2012 13:03:47 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:59032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJ5sn-00075g-Sq for emacs-devel@gnu.org; Tue, 02 Oct 2012 13:03:46 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MB900900Z7OC100@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 02 Oct 2012 19:03:44 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MB9009TJZE72G40@a-mtaout22.012.net.il>; Tue, 02 Oct 2012 19:03:44 +0200 (IST) In-reply-to: <506B1850.1070404@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:153928 Archived-At: > Date: Tue, 02 Oct 2012 09:37:36 -0700 > From: Paul Eggert > Cc: emacs-devel@gnu.org > > On 10/02/2012 06:20 AM, Stefan Monnier wrote: > > They were (or close enough) since each sample was weighted according to > > current_sampling_interval. > > On Windows they weren't. Apparently the sampling interval there > is actually 15 ms, even though we pretended it was 1 ms. Which AFAIK is (was) a bug in profiler: it cannot assume that what it asked setitimer will actually be obeyed. To see what interval is actually being loaded into the timer, one needs to call getitimer after setitimer returns. > > we have the new problem that > > starting/stopping/starting/stopping won't count correctly if > > profiler-sampling-interval is modified between the two profiler-start. > > True. That's partly why the profiler report > now says "CPU samples". Truth in advertising.... We can still translate that to time units, if we store the actual used CPU time with each sample, not the count of the theoretical sampling period. I believe on Posix systems this boils down to calling clock_gettime with the correct timer ID (and there are equivalent APIs on MS-Windows). Then we could satisfy Stefan's design goal of having compatible profiles with different sampling period. As a nice bonus, this will also handle more accurate the situation whereby the system is heavily loaded, and therefore SIGPROF is delivered with a significant delay.