You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2002/07/15 07:04:43 UTC
Faster time_now() [Was: Why not POSIX time_t?]
At 10:03 PM 7/14/2002, Ryan Bloom wrote:
>BTW, this whole conversation started because we wanted to speed up
>Apache. Has anybody considered taking a completely different tack to
>solve this problem?
>
>I know there is a patent on this, but I am willing to ignore it, and I
>am pretty sure that we can get the patent owner to let us use it. (I
>won't say who owns the patent, but if the owner wants to stand up, it
>will be obvious why I say this). We could create a separate thread to
>keep track of the current time every second. That way, the computation
>is completely removed from request processing it is just a memory
>access. On platforms without threads, we just go back to getting the
>time during request processing. That will hurt performance for those
>platforms, but I am not too concerned about that.
Such code, of course, certainly doesn't belong in apr. That's a higher
level construct that would fit well in http, or any other app that needs
such performance tweaks. The app would have to decide how to live
if it doesn't have threads available.
And there is the matter of IP :-)
Bill
Re: Faster time_now() [Was: Why not POSIX time_t?]
Posted by Ryan Bloom <rb...@ntrnet.net>.
On Mon, 15 Jul 2002, William A. Rowe, Jr. wrote:
> At 10:03 PM 7/14/2002, Ryan Bloom wrote:
>
> >BTW, this whole conversation started because we wanted to speed up
> >Apache. Has anybody considered taking a completely different tack to
> >solve this problem?
> >
> >I know there is a patent on this, but I am willing to ignore it, and I
> >am pretty sure that we can get the patent owner to let us use it. (I
> >won't say who owns the patent, but if the owner wants to stand up, it
> >will be obvious why I say this). We could create a separate thread to
> >keep track of the current time every second. That way, the computation
> >is completely removed from request processing it is just a memory
> >access. On platforms without threads, we just go back to getting the
> >time during request processing. That will hurt performance for those
> >platforms, but I am not too concerned about that.
>
> Such code, of course, certainly doesn't belong in apr. That's a higher
> level construct that would fit well in http, or any other app that needs
> such performance tweaks. The app would have to decide how to live
> if it doesn't have threads available.
>
> And there is the matter of IP :-)
Of course this doesn't belong in APR, but the only reason the whole
apr_time_t discussion came up was to fix a performance problem in
Apache. If that performance problem hadn't come up, would we have even
looked at changing the current implementation?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
Re: Faster time_now() [Was: Why not POSIX time_t?]
Posted by Ryan Bloom <rb...@ntrnet.net>.
On Mon, 15 Jul 2002, William A. Rowe, Jr. wrote:
> At 10:03 PM 7/14/2002, Ryan Bloom wrote:
>
> >BTW, this whole conversation started because we wanted to speed up
> >Apache. Has anybody considered taking a completely different tack to
> >solve this problem?
> >
> >I know there is a patent on this, but I am willing to ignore it, and I
> >am pretty sure that we can get the patent owner to let us use it. (I
> >won't say who owns the patent, but if the owner wants to stand up, it
> >will be obvious why I say this). We could create a separate thread to
> >keep track of the current time every second. That way, the computation
> >is completely removed from request processing it is just a memory
> >access. On platforms without threads, we just go back to getting the
> >time during request processing. That will hurt performance for those
> >platforms, but I am not too concerned about that.
>
> Such code, of course, certainly doesn't belong in apr. That's a higher
> level construct that would fit well in http, or any other app that needs
> such performance tweaks. The app would have to decide how to live
> if it doesn't have threads available.
>
> And there is the matter of IP :-)
Of course this doesn't belong in APR, but the only reason the whole
apr_time_t discussion came up was to fix a performance problem in
Apache. If that performance problem hadn't come up, would we have even
looked at changing the current implementation?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------