On Thu, Dec 10, 2009 at 9:07 PM, David Brownell <davi...@pacbell.net> wrote: > On Thursday 10 December 2009, Øyvind Harboe wrote: >> Some profiling information for arm7 16MHz GDB load operation shows >> gdb_get_packet_inner() near the very top. >> >> Each sample counts as 0.01 seconds. >> % cumulative self self total >> time seconds seconds calls Ts/call Ts/call name >> 52.91 2.27 2.27 embeddedice_write_dcc >> 11.89 2.78 0.51 gdb_get_packet_inner >> 8.86 3.16 0.38 memcpy >> 3.26 3.30 0.14 >> idle_thread_main(unsigned int) >> 3.03 3.43 0.13 cyg_in_cksum > > How does $SUBJECT patch change that? > > Specifically, how does affect *elapsed* time in terms > of the GDB load operation?
I want to do these optimizations in small steps so git bisect will work well. Always a nice thing I find. It improves it a little bit more than you might think because the caches can be quite a bit smaller on an embedded host. Also, once I have the inner loop a bit more isolated now, I'll be able to have a closer look at it to see if more can be done. The *huge* wins have been had so far, so now it's many small victories that are required to make a dent. GDB load is at 600kBytes/s @ 16MHz for arm7 now with zy1000 revc. Perhaps this profiling session is more illustrative. I've taken out the target_write_memory() and only profiled gdb load(1500kByte/s). As you can see gdb_get_packet_inner() will be even more important at those speeds. %s 38.82 0.59 0.59 gdb_get_packet_inner 16.20 0.84 0.25 memcpy 5.26 0.92 0.08 cyg_in_cksum 3.21 0.97 0.05 cyg_tcp_input 2.63 1.01 0.04 cyg_tcp_output 2.63 1.05 0.04 ipintr 2.22 1.08 0.03 idle_thread_main(unsigned int) 1.56 1.10 0.02 Cyg_Flag::setbits(unsigned int) 1.40 1.12 0.02 cyg_interrupt_call_pending_DSRs 1.32 1.14 0.02 Cyg_Mutex::lock() 1.32 1.16 0.02 cyg_callout_reset 1.32 1.18 0.02 cyg_in_cksum_hdr 1.32 1.20 0.02 cyg_in_cksum_skip -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
