[Libevent-users] event_queue_remove spent too much time

[Scott Lamb]

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/>