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 23:17:54 +0200 Message-ID: <83mx04a7zx.fsf@gnu.org> References: <506B1850.1070404@cs.ucla.edu> <83wqz8ajra.fsf@gnu.org> <506B5418.8030506@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1349212762 3670 80.91.229.3 (2 Oct 2012 21:19:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Oct 2012 21:19:22 +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 23:19:24 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 1TJ9rT-0004qW-AZ for ged-emacs-devel@m.gmane.org; Tue, 02 Oct 2012 23:18:39 +0200 Original-Received: from localhost ([::1]:59865 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJ9rN-0006t1-EX for ged-emacs-devel@m.gmane.org; Tue, 02 Oct 2012 17:18:33 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53641) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJ9rK-0006ss-IT for emacs-devel@gnu.org; Tue, 02 Oct 2012 17:18:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJ9rJ-000252-B4 for emacs-devel@gnu.org; Tue, 02 Oct 2012 17:18:30 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:55720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJ9rJ-00024g-2q for emacs-devel@gnu.org; Tue, 02 Oct 2012 17:18:29 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MBA00B00B3ON900@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 02 Oct 2012 23:17:44 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MBA00B0XB5K7WA0@a-mtaout22.012.net.il>; Tue, 02 Oct 2012 23:17:44 +0200 (IST) In-reply-to: <506B5418.8030506@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:153960 Archived-At: > Date: Tue, 02 Oct 2012 13:52:40 -0700 > From: Paul Eggert > CC: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > On 10/02/2012 10:03 AM, Eli Zaretskii wrote: > > To see what interval is actually being loaded into the timer, one > > needs to call getitimer after setitimer returns. > > Yes, that would have been an improvement. But it still wouldn't have > been right, as on many platforms (including mine) the actual sampling > interval differs from what timer_gettime / getitimer reports. With a > CPU thread timer I can set the sampling interval to 1 ns (!), and > timer_gettime reports that it's 1 ns, but it's actually ~1 ms because > that's how thread scheduling works. Does getitimer report correct values for reasonable intervals, though? If it does, that will be good enough for our needs. > > 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 > > Yes, that should help, but I expect it'd slow things down. On many > hosts clock_gettime is reasonably slow because it involves a system > call and whatnot. We could call clock_gettime once in 10 or 100 samples, say. Its results are cumulative, so for short periods of time, like 0.1 or 1 sec, they are still suitable for converting sample numbers to CPU times, by assuming uniform CPU percentage over that period. > More generally, there is often a performance penalty in trying to get > the time precisely, and in profiling it's often more useful to get > the time quickly than to get it precisely. Yes, but showing a vague "number of samples" is hardly useful enough. Maybe we should do the above as an option, and see if it's good enough and preferred.