From xemacs-m  Sat Jan 11 12:11:40 1997
Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54])
          by xemacs.org (8.8.4/8.8.4) with ESMTP
	  id MAA27526 for <xemacs-beta@xemacs.org>; Sat, 11 Jan 1997 12:11:39 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by UCSD.EDU (8.8.3/8.6.9) with SMTP id KAA22028; Sat, 11 Jan 1997 10:11:26 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id KAA25442; Sat, 11 Jan 1997 10:09:13 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: xemacs-beta@xemacs.org
Cc: tools-help@python.org
Subject: elp time bug (was Re: New bench.el)
References: <fawafqht1yk.fsf@mordor.rsn.hp.com>
X-Face: "oX;zS#-JU$-,WKSzG.1gGE]x^cIg!hW.dq>.f6pzS^A+(k!T|M:}5{_%>Io<>L&{hO7W4cicOQ|>/lZ1G(m%7iaCf,6Qgk0%%Bz7b2-W3jd0m_UG\Y;?]}4s0O-U)uox>P3JN)9cm]O\@,vy2e{`3pb!"pqmRy3peB90*2L
From: David Moore <dmoore@UCSD.EDU>
Date: 11 Jan 1997 10:09:12 -0800
In-Reply-To: Shane Holder's message of 10 Jan 1997 19:50:11 -0600
Message-ID: <rvsp48t77b.fsf@sdnp5.ucsd.edu>
Lines: 42
X-Mailer: Red Gnus v0.80/XEmacs 19.15

Shane Holder <holder@mordor.rsn.hp.com> writes:

> (defsubst bench-get-time ()
>   ;; Stolen from elp
>   ;; get current time in seconds and microseconds. I throw away the
>   ;; most significant 16 bits of seconds since I doubt we'll ever want
>   ;; to profile lisp on the order of 18 hours. See notes at top of file.
>   (let ((now (current-time)))
>     (+ (float (nth 1 now)) (/ (float (nth 2 now)) 1000000.0))))

	Right, I forgot to report this for elp.  The comment with this
code isn't correct.  Subtracting two values from bench-get-time
(elp-get-time) will produce a wrong result anytime you cross the boundary
where you overflow (nth 1 time) into (nth 0 time).  This event happens
every 18 hours, but can affect profiling on tasks of even 5 minutes, if
they straddle the edge.

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

;;; you can't just drop the top 16 bits.  what if we have two times
;;; which straddle the overflow of the 2nd 16 bits, then we'd
;;; incorrectly compare them.
;;; FIX FIX FIX, it might be faster to provide a routine like
;;; gnus-time-minus instead, and then convert to floating point?
(defsubst elp-convert-time (when)
  (+ (* (float (nth 0 when)) 65536)
     (float (nth 1 when))
     (/ (float (nth 2 when)) 1000000.0)))

(defmacro elp-diff-time (start end)
  `(+ (* (- (car ,end) (car ,start)) 65536.0)
      (- (cadr ,end) (cadr ,start))
      (/ (- (caddr ,end) (caddr ,start)) 1000000.0)))

-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    |

