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

Re: Some tips on profiling

From: Ramkumar Ramachandra <artagnon_at_gmail.com>
Date: Tue, 28 Sep 2010 21:22:45 +0530

Hi Stefan,

Stefan Fuhrmann writes:
> Under Linux, I'm using Valgrind / Callgrind and visualize in KCachegrind.
> That gives me a good idea of what code gets executed too often, how
> often a jump (loop or condition) has been taken etc. It will not show the
> non-user and non-CPU runtime, e.g. wait for disk I/O. And it will slow the
> execution be a factor of 100 (YMMV).

Ah, they're brilliant! Just what I was looking for :D I'm yet to
interpret the output and interpret it to opimize svnrdump though-
might need some more help there; are you available on #svn-dev or
something sometime? Will keep you updated on this either way.

> Under Windows, I'm using the VisualStudio sampling profiler. The
> measurements
> are pretty accurate and the overhead is low. It does not tell me, how often
> a certain code path has been executed. Due to the low overhead, it is
> well-suited for long running (>1 min) operations.

Interesting. I didn't know Visual Studio had a profiler. Then again,
I've not used Windows for several years now.

> Also, I find a simple "time <command>" very useful to get a first impression
> whether my code is bound by user-runtime, I/O wait or system runtime.

Ah, I want to know how to interpret this correctly. For equivalent
operations
svnrdump says: 7.49s user 1.34s system 91% cpu 9.682 total
svnadmin says: 4.84s user 0.44s system 97% cpu 5.417 total

> To collect data on I/O activity, compression rates and other not readily
> available information, I use simple static counters and printf()
> their values
> at the end of each client call, for instance.

I see.

> Hope that helps.

A ton! Thanks a lot :)

-- Ram
Received on 2010-09-28 17:55:08 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.