Robert, What are you after? prof shows garbage. Get the cpuProfiling to measure what you want. Its no way xprof_* routines take up 2% of time, thats ridiculous. They run 10-20 cpu opcodes max. prof is also very intrusive into code, changing true cpu usage splits alot. You may use it to get idea of call graphs, but actual measurements should be done with xprof probes. Also note that things change dramatically when cpu becomes a bottleneck and there are thousands of FDs open.
I'd focus of profiling when cpu usage is at ~100%. Which shows me that most problems we have are in comm_poll and acls (my workload). To be gained - ~ 15-40% On 20 Feb 2003, at 0:15, Robert Collins <[EMAIL PROTECTED]> wrote: > Flat profile: > > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 3.37 0.32 0.32 33228 0.01 0.01 headersEnd > 3.16 0.62 0.30 memPoolGet > 2.53 0.86 0.24 199695 0.00 0.00 httpHeaderIdByName > 2.11 1.06 0.20 xprof_stop > 1.48 1.20 0.14 xprof_start > 1.37 1.33 0.13 2692928 0.00 0.00 httpHeaderGetEntry > 1.16 1.44 0.11 351261 0.00 0.00 > statHistBin(_StatHist const*, double) > 1.11 1.54 0.10 519896 0.00 0.00 > cbdataInternalAlloc > 1.05 1.65 0.10 memPoolFree > > read into this what you will :}. > > What I get from it, is that the greatest single improvement we can get > is only 3%. However, the interesting ration is the self calls / % - > which is very high for headersEnd. > > Rob > > -- > GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>. > ------------------------------------ Andres Kroonmaa <[EMAIL PROTECTED]> CTO, Microlink Data AS Tel: 6501 731, Fax: 6501 725 P�rnu mnt. 158, Tallinn 11317 Estonia
