Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Mailbox-Line: From dreid@jetnet.co.uk  Mon Jul 15 15:58:49 2002
Message-ID: <00e401c22c10$5ad6f150$7500a8c0@goliath>
From: "David Reid" <dreid@jetnet.co.uk>
To: "APR Dev List" <dev@apr.apache.org>
References: <JHEPKCEMGPKFFDHHDDKDOEFCEMAA.bill@wstoddard.com>
Subject: Re: Why not POSIX time_t?
Date: Mon, 15 Jul 2002 16:00:27 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

+1 from me. Let's finish this nonsense!

david

> New proposal... leave apr_time_t exactly as it is.  The performance
problem
> is with how we are converting an apr_time_t into a value with 1 second
> resolution (ie, doing 64 bit divisions).  I propose we introduce some new
> macros (or functions) to efficiently remove resolution from apr_time_t and
> do an approximate (not precise) conversion to seconds.  Aaron (I believe)
> has already demonstrated this idea.  This is the least invasive, easiest
to
> understand and workable solution IMHO.
>
> Bill
>
> > > >>If you mean using only second-resolution times, that's an option,
> > > >>but not for the httpd.  One of the big problems with 1.3 was that
> > > >>the request time was only stored with 1-second resolution.  We used
> > > >>to have to add in custom, redundant time lookups to get better
> > > >>resolution whenever we needed to instrument request duration or
> > > >>log request times with higher precision.
> > > >>
> > > >>
> > > >
> > > >But http only requires 1 sec resolution.  If you want better than
> > that,
> > > >then you will have a performance hit.
> > > >
> > >
> > > No you won't.  It's *faster* to get the time with
> > > microsecond resolution than to get it with second
> > > resolution.  (gettimeofday() is faster than time().)
> >
> > Then get the time with microsecond resolution in the thread, but only
> > save second resolution.  This way, the 64-bit division is not happening
> > in the middle of request processing.
> >
> > > >  But what
> > > >you just said is that time code is not a performance problem.
> > > >
> > >
> > > No, I said the retrieval of the time (the thing for which you're
> > > proposing a separate thread) is not a performance bottleneck.
> > >
> > > >  So, why are
> > > >we optimzing this again?
> > > >
> > >
> > > Because 64-bit divisions are a performance problem, as
> > > seen in FirstBill's recent benchmarks.
> > >
> > > Looking up the time with microsecond resolution is not
> > > the problem.  The problem is that we do gratuitous 64-bit
> > > math once we've retrieved the time.  And the binary
> > > microsecond change is a valid remedy for that problem.
> >
> > Yes it is, but it isn't the ONLY valid remedy.  Since that change is
> > causing a lot of grief, I am asking us to consider other remedies.
> >
> > Ryan
> >
> >
> >
>
>
>
>