jenkins svn plugin revert action slower than command line job?

I have three build machines with Jenkins v1.473 installed.

Let's call them machine A, B and C. All are running Windows 7 x64. Machine B and C jenkins installation was carried over from machine A. I simply copied the folder over and everything was imported and works fine.

We initially had a Windows command line job that would call svn revert and then, svn update on a bunch of folders. After that, we would build our project. The average running time was about 10 mins. SVN version of the command line tools is 1.7 on all 3 machines (with tortoisesvn)

Since we were using command line svn commands, we didn't have access to $CHANGES when sending the job completion email, so we switched to the Jenkins svn plugin. The switch was made on machine B and C first and after confirming it was working fine, we applied the same changes to machine A. The plugin version is 1.50.

Check-out Strategy is set to "Use 'svn update' as much as possible, with 'svn revert' before update". Repository browser is set to Auto.

Under Jenkins->Configuration, Subversion Workspace Version is set to 1.7. The other fields are left as-is (Exclusion revprop name is empty, Validate repository URLs up to the first variable name is unchecked, Update default Subversion credentials cache after successful authentication is checked)

Now, onto my issue.

The running time on machine B and C stayed about the same: about 10 mins.

However, on machine A, running time has more than doubled: it now averages 25 mins. Looking at the job log, the revert part seems to be the culprit.

Is there a reason switching from svn command line to the plugin would make it run slower ? On top of that, on one particular machine only ?

Solution

After digging and testing several jobs across all machines, here's what I found out:

command line tools are fairly faster than their plugin counterpart, most likely due to the speed of the programs themselves (compiled C binary vs SVNKIT which is written in Java and running on top of a JVM)
machine A is also fairly slower than B and C, despite having similar specs, most likely because of other applications and services running at the same time (B and C are near-fresh installs, while A has been running for a longer time, with more applications installed etc)

In the end, I just split the clean/revert part from the update:

Clean/Revert job is carried in command line (I/O heavy due to folder traversal I believe) so it is as fast as it can be
Update (and update only, no revert done within the plugin) is then done with the plugin (fairly fast, less than a minute usually for several dozen files) which allows me to still have access to the CHANGES variable.

With this, I somehow managed to keep the building time on machine A nearly unchanged (around 10 mins). Machines B and C however, have seen their building times greatly improved (from 10 mins to 5 mins in general)