Edward Ned Harvey wrote on Fri, 2 Jul 2010 at 20:11 -0400: > Long story short, I tried like hell to get the profiler to work, and didn't > succeed. I absolutely verified the -pg option was on both the compile and > the link, by reading through the output of "make." Still, the results I got > were as previously posted: basically all zeros.
The concerning thing is not all-zeroes --- isthat only functions from subversion/svn/ appeared in the output. > I did check ldd, to ensure > what I linked against. Everything was good (linked against my build > directory where -pg was used), except: > > libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00000034a9900000) > libm.so.6 => /lib64/tls/libm.so.6 (0x00000034a6100000) > libssl.so.4 => /lib64/libssl.so.4 (0x00000034ab400000) > libcrypto.so.4 => /lib64/libcrypto.so.4 (0x00000034aab00000) > libuuid.so.1 => /lib64/tls/libuuid.so.1 (0x00000034a5a00000) > librt.so.1 => /lib64/tls/librt.so.1 (0x00000034a8900000) > libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00000034ad100000) > libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00000034a6300000) > libdl.so.2 => /lib64/libdl.so.2 (0x00000034a5f00000) > libz.so.1 => /usr/lib64/libz.so.1 (0x00000034a6900000) > libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 > (0x00000034aa900000) > libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00000034a9100000) > libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00000034a9700000) > libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00000034a8f00000) > libresolv.so.2 => /lib64/libresolv.so.2 (0x00000034a6d00000) > libexpat.so.0 => /usr/lib64/libexpat.so.0 (0x00000034a7700000) > libc.so.6 => /lib64/tls/libc.so.6 (0x00000034a5c00000) > /lib64/ld-linux-x86-64.so.2 (0x00000034a5800000) > No libsvn_* here in the exceptions; good. > I went back to the printf() method, and here's what I found: > > During the commit, which should take 11sec but actually takes 15min, while > staying 100% cpu-bound ... > > svn/main.c calls (*subcommand->cmd_func)(os, &command_baton, pool) > I assumed correctly, the above is actually svn_cl__commit() > svn/commit-cmd.c calls svn_client_commit4() > libsvn_client/commit.c calls svn_client__do_commit() > libsvn_client/commit_util.c calls svn_wc_transmit_text_deltas2() > libsvn_wc/adm_crawler.c calls svn_txdelta_send_txstream() > and finally, > > in this file: libsvn_delta/text_delta.c > this function: svn_txdelta_send_txstream() > it cycles in the do...while() loop many times. During each cycle, the bulk > of time is spent in this command: > /* shove it at the handler */ > SVN_ERR((*handler)(window, handler_baton)); > By the way, HANDLER here is the "transmit deltas to the server" callback. > FYI, the data I'm trying to commit is OpenAccess database. That is, a > database file which represents hardware chip design, schematics, blocks, > transistors, etc. I believe, from rev to rev of this data file, there's a > lot of data repetition, copy, move, shift, insert a byte in the middle of > the file ... delete a byte from the middle of the file ... that sort of > stuff. > May want to have a look at the rsync algorithm (see rsync.tex in the rsync source distribution). Maybe there's some debug mode for rsync that can help you see the structure here. > Not sure what I should look at next. Should I try to figure out what > (*handler) is? Is there a way to know what it is? > gdb, set a breakpoint, and print the value of 'handler'. Or just single-step into it. (And if the single-step doesn't step INTO it, then you're probably still using the wrong libraries...) > Thanks again... > >
