apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: [PATCH] possible optimization in apr_poll()?
Date Mon, 15 Jul 2002 04:51:43 GMT
rbb@apache.org wrote:

>>>I would not support this change, simply because I don't see it making a
>>>huge difference.  We are better off fixing the apr_time_t implementation
>>>and then looking for things like this.
>>I agree.  Once we go to the binary microsecond implementation,
>>what we'll be able to do within poll is:
>>  - extract the microseconds with a bitwise AND (encapsulated within
>>    apr_time_usec())
>>  - cast to 32 bits if the macro doesn't do so automatically
>>  - then do a 32-bit division by 1000 to get milliseconds (which
>>    is a lot cheaper than the current 64-bit division on 32-bit
>>    platforms)
>Or make apr_interval_time a 32-bit value to begin with.   :-)

My only objection to using a 32-bit apr_interval_time is that
a main reason for using a scalar representation for times is
to make it easy to do math using the native arithmetic operators.
If apr_interval_time were a 32-bit count of microseconds, we
wouldn't be able to add it to apr_[whatever_we_call_time_now]_t
without a conversion macro.


View raw message