On Feb 10, 2007, at 9:29 AM, Person wrote:
Hi,
Is it normally that high cost function call issue about
event_queue_remove()?
I profiles my program with gprof. I found the most spent time
function call is event_queue_remove().
However, I only remove events when connection is closed (conn_drop()).
There are two types events with flag EV_WRITE and (EV_READ |
EV_PERSIST) in my program. And, there are about 250 connections and
250*2 events (read and write fd).
Well, event_queue_remove() is getting called in three different ways.
From least to most often,
* Twice from each conn_drop(), on the EVLIST_INSERTED queue.
* Once implicitly on each write callback on the EVLIST_INSERTED
queue, since you're not using EV_PERSIST on writes
* Once on each callback on the EVLIST_ACTIVE queue.
It just removes the event from a doubly-linked list in O(1) time. So
even with so many calls, I'm surprised to see that 8.65%. A few
thoughts:
* If this trivial function is so high up on the CPU usage, is your
program not CPU-bound at all?
* Does gprof add overhead to each function call? I don't remember how
it works, but if it does, this might unfairly penalize quick but
often-called functions like event_queue_remove(). Seems like
event_queue_insert() should be in the same boat, though...it gets
called as often and does a very similar thing.
* Maybe event_queue_remove() is getting a disproportionate number of
cache misses and waiting for memory access? Does "valgrind --
tool=cachegrind" give this kind of information?
Cheers,
Scott
--
Scott Lamb <http://www.slamb.org/>
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
