apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: APR and Apache Time Format Questions
Date Mon, 03 Mar 2003 20:21:27 GMT
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

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@.


At 01:03 PM 3/3/2003, Jean-Jacques Clar wrote:
>I have two Questions/Suggestions to improve the current performance 
>of Apache 2.
>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).
>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,

View raw message