[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: xdelta, svndiff, zlib, or some other problem

From: Edward Ned Harvey <svn_at_nedharvey.com>
Date: Fri, 2 Jul 2010 20:11:37 -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. 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
        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)

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));

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

I was not able to replicate the problem using random data. This problem is
only happening with real data.

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?

Thanks again...
Received on 2010-07-03 02:12:24 CEST

This is an archived mail posted to the Subversion Dev mailing list.