On Mon, Dec 17, 2007, Tsantilas Christos wrote: > Hi Adrian, > As I am seeing squid3 spends time in EventScheduler::schedule method. > This method did not affected by the new AsyncCall code. Also this method > is similar with squid 2.6 eventAdd function.
Yes, but you're using an event system which wasn't designed for massive amounts of immediate events for, well, massive amounts of immediate events. > The only I can say is that possibly we are scheduling a huge number of > events in squid3. > If the time spend while creating the ev_entry class possibly we need a > (better?) memory allocator. .. or don't allocate so many of them. > Also there is a for loop in this method. Most event scheduled with when=0 > so they attached at the end (or near the end) of the events list (but we > are running all the list). If we have a big number of events (1000 or > more) it is possible to spend a lot of time here. > But if this is the problem it is easy for someone to fix it, we must not > worry about it at this time.... As the guy who found the bung garbage collection in Squid-3 at least 12 months ago, causing CPU to chewed through at a crazy rate, I think its worth keeping this in mind and thinking (and benchmarking!) a way around this. It shouldn't be that difficult. But what I don't want to see is someone building an interface which will perform badly, do a whole lot of work within it, commit sweeping changes to how things are done, and then wonder why stuff performs badly. I'm sure its something like: for (E = &tasks; *E; E = &(*E)->next) { if ((*E)->when > event->when) break; } And > should be >=, so it doesn't walk a whole lot of 0.00 (now) events waiting for them to complete. Of course, what you guys -should- be doing really is not using this loop, but instead building a simple dlink list (or whatever data type in C++ is comparable) and just appending events to the end. O(1) and all that. This event loop is for scheduling events at some point in the future and I think overloading it is a bit silly. Adrian