On Wed, Jul 27, 2011 at 11:00:45PM -0400, Nick Mathewson wrote:
> On Wed, Jul 27, 2011 at 10:35 PM, William Ahern
> wrote:
>
> If you happen to know, is it the same story with clock_gettime()
> performance? I ask because Libevent uses that function in preference
> to gettimeofday() when it's ava
On Wed, Jul 27, 2011 at 10:35 PM, William Ahern
wrote:
If you happen to know, is it the same story with clock_gettime()
performance? I ask because Libevent uses that function in preference
to gettimeofday() when it's available.
yrs,
--
Nick
*
On Wed, Jul 27, 2011 at 07:03:33PM -0700, William Ahern wrote:
> However, the difference between vDSO support and no vDSO support was nothing
> compared to the OpenBSD v. Linux differences. OpenBSD system calls are
> incredibly slow compared to Linux. A million gettimeofday calls on OpenBSD
> take
On Wed, Jul 27, 2011 at 10:10:36PM +0100, Nicholas Marriott wrote:
> On Wed, Jul 27, 2011 at 01:10:05PM -0700, William Ahern wrote:
> > Has anyone tested the performance gain of caching? Linux's gettimeofday()
> > doesn't trap into the kernel; it effectively just reads a shared memory
> > page. II
AFAIK this optimization in Linux is only available on some architectures
and there is a knob with several possible settings.
Without this, gettimeofday() can be quite expensive.
On Wed, Jul 27, 2011 at 01:10:05PM -0700, William Ahern wrote:
> On Wed, Jul 27, 2011 at 02:49:26PM -0400, Nick Mathew
On Wed, Jul 27, 2011 at 02:49:26PM -0400, Nick Mathewson wrote:
> So because I'm at a conference this week, I can't examine the code too
> closely. But my guess is that this is happening because Libevent
> caches its calls to gettimeofday()/clock_gettime() during its event
> loop, so that your ev
On Wed, Jul 27, 2011 at 11:24 AM, Leonid Evdokimov wrote:
> Hello all,
>
> I assumed, that timeout is never(!) scheduled a-bit-earlier than
> requested and today I see, that either my assumption is wrong, or I
> became a bit insane while writing the code.
>
> I attached simple test for the asserti
Hello all,
I assumed, that timeout is never(!) scheduled a-bit-earlier than
requested and today I see, that either my assumption is wrong, or I
became a bit insane while writing the code.
I attached simple test for the assertion. For example, I've got
following strange results:
$ ./event-timeout
