Re: [Libevent-users] Libevent 1.4.9-stable slower than 1.3c?
Just FYI,
gettimeofday() is expensive on platforms (like FreeBSD) which actually attempt
to return very precise timestamps.
Adrian
On Tue, Apr 14, 2009, Haiping Zhao wrote:
Niels,
I found out why. 1.4.9 has a tv_cache in gettime():
static int
gettime(struct event_base *base, struct timeval *tp){
if (base-tv_cache.tv_sec) {
*tp = base-tv_cache;
return (0);
}
(omitted)...
}
We happened to use timer as our message pump (my original statement about
using timer as timeout management wasn't quite right after I read the code)
to process some UDP packets. But then, this cached timestamp can be 1 to 3ms
out of date in our code. So the whole pumping was slowed down 2x. I confirmed
this by dumping all timeout_process()'s timestamps when an event is detected
as timed-out, and all of them were shifted or lagged behind than the ones
collected with 1.3c build.
Anyways, I'll have to re-think our model. At the same time, may I ask why the
change? Was that for calling gettimeofday() less number of times to be more
efficient? But the code only updates base-tv_cache once per loop, each of
which may take several milliseconds to finish. Doesn't that leave huge space
for an inaccurate timestamp?
-Haiping
On 4/14/09 4:59 PM, Niels Provos pro...@gmail.com wrote:
On Tue, Apr 14, 2009 at 3:37 PM, Haiping Zhao hz...@facebook.com wrote:
We have a piece of code that was using 1.3c, and when I switched it to use
1.4.9-stable, I found it's 2x slower, spending almost all extra time in I/O
waiting. This piece of code does simple UDP handling, and we do have timers
going on for timeout management.
I am not aware of anything that would have made libevent slower
between 1.3 and 1.4. It should be slightly faster actually.
What do you mean by I/O waiting? Your code is blocking on IO?
Niels.
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
--
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
[Libevent-users] bug in min_heap
Given heap shape of: 1 / \ / \ 10 3 / \ / \ 11 12 5 6 And now deleting '11', it seems to fail to keep heap property. The bug is probably hard to notice in practice as the events will reach top anyway, only later than expected. Btw, I did not got feedback on my event struct size decreasing patch: http://monkeymail.org/archives/libevent-users/2008-July/001346.html 24 bytes on 64-bit platforms may not sound like a big memory saving, but if we want to process tens or even hundreds of thousands of events with maximum efficiency, then best use of CPU caches becomes important. And there the bytes can matter. -- marko ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] bug in min_heap
On 4/15/09, Nick Mathewson ni...@freehaven.net wrote:
On Wed, Apr 15, 2009 at 01:01:00PM +0300, Marko Kreen wrote:
Given heap shape of:
1
/ \
/ \
10 3
/ \ / \
11 12 5 6
And now deleting '11', it seems to fail to keep heap property.
The bug is probably hard to notice in practice as the events
will reach top anyway, only later than expected.
Got a patch for this?
Well, I attached a draft of it, but its totally untested and the
minheap code is not very parseable for me. So somebody with
has better understanding of the code should review it. (Maxim?)
Basic idea - if you replace an element in the middle of heap with
last element, there is chance it needs to be pushed up not down.
I found it when writing heap code for my own small libevent-compatible
event loop. I've used to writing against libevent API, but when the
program will process only small number of connections, it seems
unnecessary to create libevent dependency for it. Code can be seen here:
http://github.com/markokr/libusual/blob/0812279371dcf07ea3961642ecf88403dceda2e6/usual/heap-impl.h
Btw, I did not got feedback on my event struct size decreasing patch:
http://monkeymail.org/archives/libevent-users/2008-July/001346.html
24 bytes on 64-bit platforms may not sound like a big memory saving,
but if we want to process tens or even hundreds of thousands of events
with maximum efficiency, then best use of CPU caches becomes important.
And there the bytes can matter.
This looks pretty good. I'll apply it in 2.0;
Thanks.
I'd prefer to leave the
struct layout alone for the 1.4 series so as not to break binary
compatibility more than necessary.
Yeah, thats reasonable.
--
marko
Index: minheap-internal.h
===
--- minheap-internal.h (revision 1174)
+++ minheap-internal.h (working copy)
@@ -88,7 +88,12 @@
{
if(((unsigned int)-1) != e-min_heap_idx)
{
-min_heap_shift_down_(s, e-min_heap_idx, s-p[--s-n]);
+ struct event *last = s-p[--s-n];
+unsigned parent = (e-min_heap_idx - 1) / 2;
+ if (e-min_heap_idx 0 min_heap_elem_greater(s-p[parent], last))
+min_heap_shift_up_(s, e-min_heap_idx, last);
+ else
+min_heap_shift_down_(s, e-min_heap_idx, last);
e-min_heap_idx = -1;
return 0;
}
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
