Perhaps this will just result in "tell me something I don't know". However, I was running recent code for several days. A lot of the time was spent as an ultra-node. Some other GTKG leafs were connected for several days.
Here is the synopsis of gprof output... Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 23.80 27809.42 27809.42 2788473 0.01 0.01 qrt_apply_patch 3.52 31917.65 4108.23 257788823 0.00 0.00 strcmp_delimit_full 2.94 35349.41 3431.76 cell_renderer_func 2.67 38470.78 3121.37 3664755 0.00 0.00 pcache_pong_received 2.61 41520.95 3050.17 2901852 0.00 0.01 call_node_process_handshake_header 2.61 44567.45 3046.50 60840405 0.00 0.00 header_append 1.94 46838.45 2271.00 3080131 0.00 0.00 qrt_build_query_target 1.03 48039.48 1201.03 11285540 0.00 0.00 utf8_remap 1.01 49214.68 1175.20 338047622 0.00 0.00 bws_can_connect The qrt_apply_patch() has three nested for loops. I also imagine that these are continually updated by all leaf nodes and this has to be digested to pass along the info to the ajoining ultras [and leaves?]. Is it possible to improve qrt_apply_patch() or has it been well studied? The total bzipped output of gprof (and ident) is 155k... so I didn't post to the list. fwiw, Bill Pringlemeir. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Gtk-gnutella-devel mailing list Gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
