Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3D323EBE.2090002@apache.org>
Date: Sun, 14 Jul 2002 20:17:18 -0700
From: Brian Pane <brianp@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: Why not POSIX time_t?
References: <00b201c22bac$3f8bc8d0$0a01230a@KOJ>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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?  
>

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.

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

What problem are you trying to solve with this separate
thread?  If it's "speeding up time lookups," I think the
effort is misguided, for two reasons:
  1. Many modern operating systems already have well-
     optimized implementations of gettimeofday() that
     don't involve much more than a read from a memory
     address that contains the current time.
  2. The gettimeofday() is fast compared with the real
     bottlenecks in time processing: expanding the time
     into a struct tm and formatting it in human-readable
     form.  (We've already solved both of these in 2.0
     with caching solutions, and the time code no longer
     registers as a significant expense in performance
     profiling.)

--Brian