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...
>
>
Received on 2010-07-03 08:27:35 CEST