Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.2.0.9.2.20030303140610.03b5ddd0@pop3.rowe-clan.net>
Date: Mon, 03 Mar 2003 14:21:27 -0600
To: "Jean-Jacques Clar" <JJCLAR@novell.com>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: APR and Apache Time Format Questions
Cc: <dev@apr.apache.org>
In-Reply-To: <se634496.072@prv-mail20.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

You can't accomplish your patch and maintain binary compatibility
between different 'flavor builds' of APR.  Plus the number of bugs that
would occur would be a huge pain.

This has been debated many times on list, please query the archives
<http://marc.theaimsgroup.com/?l=apr-dev>

Different proposals have included using tm structures; going back to
seconds (not apr_time_t) for those functions that clearly only benefit
from 1sec resolution; and even binary microsecond resolution.  There
really hasn't been one definitive agreement, claims that "httpd only
benefits from 1sec resolution" are balanced against "most platforms
support sub-sec resolution for file times and other values, either 1ms,
1us, and sometimes even sub-1us values like NT's 100ns units".

It's a very uneasy consensus and one that is not very stable.  But any
arguments to change the definition of "apr_time_t" are likely to fall on
deaf ears - if you care to propose another type-name to represent 
whatever it is you are inventing - the list would be much more receptive.
Many bugs were cause by changing the time definition, more bugs 
will inevitably be introduced by changing it yet again.  A different type 
would help developers identify their mistakes, a type that doesn't
auto-resolve to an int would help even more :-)

Oh - this discussion belongs on apr@ ... discussing changing the
definition of time within httpd belongs on httpd@.

Bill

At 01:03 PM 3/3/2003, Jean-Jacques Clar wrote:
>I have two Questions/Suggestions to improve the current performance 
>of Apache 2.
> 
>1: 
>Apache and Apr are keeping the time stamp in uSEC, it implies multiple 
>calls to apr_time_sec(), which is just doing a 64 bits division to transform 
>uSEC in sec. 
>I think this is a waste of CPU cycles for nothing.
> 
>What about creating a new define called: 
> 
>#define APR_HAS_USEC.
> 
>The else of that option could allow apache to run using ONLY sec for all 
>apr_time_t field removing all 64 bits division to transform uSEC to sec.
>The size of the apr_time_t variables could also be changed to 32 bits and 
>calls to gettimeofday() changed to time() in that configuration.
> 
>Why is apache using uSEC? 
>Time variables are mostly used in seconds at run-time, and http 
>requirements use seconds.
> 
>The performance gain is minor but measurable: between 1 and 2.5% on 
>my box (from 1 to 4 CPUs).
> 
>-----------
> 
>Questions: 
>2-
>If one does not fly, it should also be valuable to change the return format 
>of apr_date_parse_http() to be in seconds instead of uSEC.
>This is a snippet of the last part of that function:
> 
>--- boc ---
>    /* ap_mplode_time uses tm_usec and tm_gmtoff fields, but they haven't 
>     * been set yet. 
>     * It should be safe to just zero out these values.
>     * tm_usec is the number of microseconds into the second.  HTTP only
>     * cares about second granularity.
>     * tm_gmtoff is the number of seconds off of GMT the time is.  By
>     * definition all times going through this function are in GMT, so this
>     * is zero. 
>     */
>    ds.tm_usec = 0;
>--- eoc ---
> 
>and then the time is exploded to match the apr_time_t format.
> 
>A call to apr_date_parse_httpd() is usually followed by a call to apr_time_sec(), 
>which do a 64 bits division to get the time in second.
>What about having a new function called apr_date_parse_httpd_sec(), which 
>skip the end part of apr_time_exp_get() and return seconds?
>It implies a small change to apr_time_exp_get() and moving the core code in 
>apr_time_exp_get() to apr_time_exp_get_sec().:
> 
>--- boc ---
>APR_DECLARE(apr_status_t) apr_time_exp_get(apr_time_t *t, apr_time_exp_t *xt)
>{
>    apr_status_t ret;
> 
>    ret = apr_time_exp_get_sec(t, xt);
>    if (ret == APR_SUCCESS)
>        *t = *t * APR_USEC_PER_SEC + xt->tm_usec;
> 
>    return ret;
>}
>--- eoc ---
> 
>Thank you,
> 
>Jean-Jacques