Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 46525 invoked by uid 500); 16 Jul 2002 15:45:52 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 46514 invoked from network); 16 Jul 2002 15:45:52 -0000 Message-ID: <3D343FB2.1010203@apache.org> Date: Tue, 16 Jul 2002 08:45:54 -0700 From: Brian Pane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: APR Development List Subject: Re: approximating division by a million Re: Why not POSIX time_t? References: <3D332EE3.50303@apache.org> <3D3424DC.2080306@algroup.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Ben Laurie wrote: > Brian Pane wrote: > >> Building upon Cliff's formulas, here's another idea >> for doing faster conversions of the current apr_time_t >> format to seconds: >> >> What we want is t/1000000 >> >> What we can do easily is t/1048576 >> >> But what can we add to t/1048576 to approximate t/1000000? >> >> If I solve for 'C' in >> t/1000000 = t/1048576 + t/C >> I get C= ~21,586,297 >> That's not a power of 2, but what if use 2^24 (~16M) as an >> approximation: >> >> seconds = (t >> 20) + (t >> 24) >> >> That probably isn't accurate enough, but you get the basic idea: >> sum a couple of t/(2^n) terms to approximate t/1000000. >> >> What do you think? > > > I think you're all nuts. Are you seriously saying we compute time > stuff often enough to care how long it takes? Yes. The product of: frequency of time manipulation * cost of time manipulation is high enough to make 64-bit division one of the top 5 most expensive functions in the httpd. (See Bill Stoddard's dev@httpd posts on performance profiling for some examples.) This result doesn't mean that time manipulation is naturally an expensive part of the httpd, though; rather, it means that we're using a time representation that's mismatched to the needs of the application. --Brian