Wild fuzzy handwaving offering of direction follows . . .

You're probably not going to get really accurate times as the SVN client itself doesn't provide that information. You might could use Expect or IPC::Run to open a pty which is reading from your svn co URL process and use Time::HiRes to note duration between when lines for each file are emitted (you'd want to make sure it's on a pty so that its STDOUT hopefully doesn't go into buffered mode). After the checkout is done you'd go back and compute the rate by looking at the final size of the file (but keep in mind that SVN keeps another copy of the current revision's contents stashed locally so there's probably some extra time for the local copying embedded in those values).

If that's not precise enough you might want to look at the swig interface to the underlying SVN API; however I don't know if you wouldn't wind up rewriting most of svn co in order to get things instrumented at the right places to get the numbers in which you're interested. Not to mention the SVN API's kinda hairy at the lower levels . . .

Also something like File::Magic could be of interest in determining what kind of contents files have.

Update: Tweaked second paragraph.

I have a script testing the performance and one of the requirement is to know the data transfer in the svn checkout command. I have a question how can I get it using perl. benchmark gives only the time it takes between the command start and command end. timethis was also not useful to me. I am looking for suggestions so I can improve my script.

Transfer rate is the time it took to perform the transfer — the difference between the results of two calls to time — divided by amount of data transfered. Using time from Time::HiRes will provide greater accuracy.

The interesting actions in any source management system are committing, branching, merging and updating. And those depend much more on the underlying architecture than whatever you're measuring right now.

Here's linus calling you stupid and ugly :-)

I haven't used SVN much but if it is anything like ClearCase then the larger the file is, the longer the checkout takes. I have a file that is roughly 1.5G and it takes between 20 and 30 minutes to check it out with ClearCase. :(

Well, I'm fairly confident that you don't have a single 1.5Gb file of source code, so you may want to reconsider the usefulness of putting that file in any kind of source control system.

FTR: adding large blobs into SVN will give you similar results.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Perhaps the simplest method would be to set up a custom proxy and modify your subversion configuration to go through that. You could then log whatever information to whatever accuracy you need.