From xemacs-m  Mon Jan 13 12:04:43 1997
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1])
          by xemacs.org (8.8.4/8.8.4) with SMTP
	  id MAA06163 for <xemacs-beta@xemacs.org>; Mon, 13 Jan 1997 12:04:42 -0600 (CST)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa16749;
          13 Jan 97 12:58 EST
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id MAA17168; Mon, 13 Jan 1997 12:58:06 -0500
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id MAA07381; Mon, 13 Jan 1997 12:58:05 -0500
Date: Mon, 13 Jan 1997 12:58:05 -0500
Message-Id: <199701131758.MAA07381@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
To: David Moore <dmoore@ucsd.edu>
Cc: xemacs-beta@xemacs.org, tools-help@python.org
Subject: Re: elp time bug (was Re: New bench.el)
References: <fawafqht1yk.fsf@mordor.rsn.hp.com>
	<rvsp48t77b.fsf@sdnp5.ucsd.edu>
Reply-To: tools-help@python.org
X-Attribution: BAW
X-Oblique-Strategy: Cascades
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "DM" == David Moore <dmoore@ucsd.edu> writes:

    DM> Subtracting two values from bench-get-time (elp-get-time) will
    DM> produce a wrong result anytime you cross the boundary where
    DM> you overflow (nth 1 time) into (nth 0 time).  This event
    DM> happens every 18 hours, but can affect profiling on tasks of
    DM> even 5 minutes, if they straddle the edge.

You're right of course, the code was bogus.  I've fixed this for the
next version, using your approach.

    DM> I use the following in my newer elp, which I should really
    DM> comment and get sent out (it supports call-tree profiling in
    DM> addition to the flat profling of the current version).

Feel free to send the changes to me directly and I'll integrate them
into the main branch.  If the call-tree profiling changes are
substantial, I might ask you to sign the necessary FSF papers, or
otherwise make arrangements with RMS.  Would that be a problem for
you?

-Barry

