<p>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.<br>
</p>
<p>Sent from my Android, please excuse the brevity. </p>
<div class="gmail_quote">Am 08.08.2011 14:25 schrieb "Gregory Collins" <<a href="mailto:greg@gregorycollins.net">greg@gregorycollins.net</a>>:<br type="attribution">> Not really. tryTakeMVar and tryPutMVar are pretty heavyweight and involve<br>
> taking a mutex lock:<br>> <br>> <a href="http://hackage.haskell.org/trac/ghc/browser/rts/PrimOps.cmm#L1440">http://hackage.haskell.org/trac/ghc/browser/rts/PrimOps.cmm#L1440</a><br>> <br>> IORef is much lighter-weight, see e.g.<br>
> <br>> atomicModifyMutVar#:<br>> <a href="http://hackage.haskell.org/trac/ghc/browser/rts/PrimOps.cmm#L253">http://hackage.haskell.org/trac/ghc/browser/rts/PrimOps.cmm#L253</a><br>> <br>> and<br>> <br>
> readMutVar# / writeMutVar#:<br>> <a href="http://hackage.haskell.org/trac/ghc/browser/compiler/codeGen/CgPrimOp.hs#L128">http://hackage.haskell.org/trac/ghc/browser/compiler/codeGen/CgPrimOp.hs#L128</a><br>> <br>
> The readMutVar primop just does a read (which turns into a small number of<br>> assembly instructions), and the writeMutVar primop just does a store and<br>> then marks the location dirty in the garbage collector. Doing an<br>
> atomicModifyMutVar# involves a CAS which is also typically cheaper than<br>> mutex locking (you spin-loop instead of doing blocking/wakeup semantics).<br>> <br>> For the Snap date-caching code, we only mess with mutex locks if the date<br>
> thread has been idle for a couple of seconds, in which case we don't mind<br>> paying the overhead of doing the locking. It's the "X hundred/thousand QPS"<br>> case we're trying to optimize.<br>
> <br>> G<br>> <br>> On Sun, Aug 7, 2011 at 12:20 AM, Greg Weber <<a href="mailto:greg@gregweber.info">greg@gregweber.info</a>> wrote:<br>> <br>>> couldn't tryTakeMVar and tryPutMVar handle this case of multiple writers<br>
>> well? I am asking because I really don't know :)<br>>><br>>> On Sat, Aug 6, 2011 at 2:05 PM, Gregory Collins <<a href="mailto:greg@gregorycollins.net">greg@gregorycollins.net</a>>wrote:<br>>><br>
>>> On Sat, Aug 6, 2011 at 8:11 PM, Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>>wrote:<br>>>><br>>>>> Without having delved into the issue in any great depth, I had a<br>
>>>> possible idea on this point. How about storing an IORef containing a<br>>>>> time and the text representations you need. Whenever you need to get<br>>>>> the time, compare the time in the IORef with the current time, and if<br>
>>>> they're different, update appropriately. Bonus points: store in an<br>>>>> unpacked datatype and use a Builder instead of String. Would this (in<br>>>>> theory) work?<br>>>>><br>
>>><br>>>> We do something similar to this, except we get the thread to recompute the<br>>>> date -- otherwise every second you have a race condition possibility where<br>>>> multiple threads compete to write the new thread into the IORef. If there's<br>
>>> no activity, the date thread goes to sleep, the code to get the current date<br>>>> notices that the date is stale, and then it wakes the thread and recomputes<br>>>> the new date itself. Again, I'm not sure if it's worth it in the general<br>
>>> case, but during periods of high load I think it helps to get as much stuff<br>>>> out of the processing threads as possible.<br>>>><br>>>> G<br>>>> --<br>>>> Gregory Collins <<a href="mailto:greg@gregorycollins.net">greg@gregorycollins.net</a>><br>
>>><br>>>> _______________________________________________<br>>>> web-devel mailing list<br>>>> <a href="mailto:web-devel@haskell.org">web-devel@haskell.org</a><br>>>> <a href="http://www.haskell.org/mailman/listinfo/web-devel">http://www.haskell.org/mailman/listinfo/web-devel</a><br>
>>><br>>>><br>>><br>> <br>> <br>> -- <br>> Gregory Collins <<a href="mailto:greg@gregorycollins.net">greg@gregorycollins.net</a>><br></div>