On Mon, Aug 8, 2011 at 2:41 PM, Aristid Breitkreuz <aristidb@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 :( G -- Gregory Collins <greg@gregorycollins.net>