[web-devel] Caching the System time

Gregory Collins greg at gregorycollins.net
Mon Aug 8 15:01:07 CEST 2011

On Mon, Aug 8, 2011 at 2:41 PM, Aristid Breitkreuz
<aristidb at googlemail.com> wrote:
> When I measured it, gettimeofday/clock_gettime took less than a microsecond. Make sure the overhead of having a dedicated thread for time caching doesn't slow things down. My test was on x86 Linux on some 2009 Intel Xeon.

Again -- we're not caching for the time of day, we're caching the
generated string representation (i.e. "Mon, 08 Aug 2011 12:49:05
GMT"). This string is sent with every HTTP response and it only
changes once per second; the overhead involved with waking up and
scheduling the green thread which updates this value would be
completely dominated by the number of cycles spent generating this
string 1,000 times per second.

There is an argument to be made that instead of a dedicated clock
update thread, every thread should:

  * call gettimeofday()

  * read an IORef-cached version to check if the current value is stale

    * if not, read the cached IORef string representation

    * if so, generate the necessary string representations (there are
several) and write them into IORef caches

There's a small risk of generating the string representations twice in
this case, so we elected not to do it -- but actually I just realized
we're not doing this properly. :(

We're calling "tryPutMVar" in the inner loop -- that should probably
be a "writeIORef" there, with the tryPutMVar moved into the "when old"
branch. I guess I wrote this before I realized how expensive
tryPutMVar was :(

Gregory Collins <greg at gregorycollins.net>

More information about the web-devel mailing list