0
\$\begingroup\$

The following script runs on a Scheduled Task on Windows 7 with a quad core 2.5GHz and 16GB of DDR3.

It makes the server unavailable for about 10 minutes, so it can produce a 500MB file, and this is only increasing.

How can I speed this up?

@echo off
mode con cols=33 lines=3 >nul
color 1F
if "%1"=="done" goto runtime
start "" /min %0 done
exit

:runtime
title Backing up SVN
echo.
echo.
echo  Backing up SVN... do NOT close!
for /f "tokens=1-4 delims=/ " %%a in ('date /t') do (set bdate=%%c-%%b-%%a)
for /f "tokens=1-2 delims=/:" %%a in ('time /t') do (set btime=%%a-%%b)
cd %temp%
rd /s /q svnbackup >nul 2>&1
md svnbackup
cd svnbackup
md certs
md conf
md uncommitted_db-pc
cd uncommitted_db-pc
net stop VisualSVNServer >nul 2>&1
svn status C:\SVN-EDGE>files.txt
for /F "tokens=1*" %%T in ('svn status C:\SVN-EDGE') do xcopy "%%U" ".\%%~pU" /F /H /K /X /Y /R /Q >nul 2>&1
svn status C:\INTERNAL>>files.txt
for /F "tokens=1*" %%T in ('svn status C:\INTERNAL') do xcopy "%%U" ".\%%~pU" /F /H /K /X /Y /R /Q >nul 2>&1
svn status C:\RESTRICTED>>files.txt
for /F "tokens=1*" %%T in ('svn status C:\RESTRICTED') do xcopy "%%U" ".\%%~pU" /F /H /K /X /Y /R /Q >nul 2>&1
cd ..
"%ProgramFiles%\7-Zip\7z.exe" a -mx9 uncommitted_files.7z uncommitted_db-pc\* >nul 2>&1
rd /s /q uncommitted_db-pc >nul 2>&1
svnadmin dump --deltas --quiet S:/Customers > Customers.dump
svnadmin dump --deltas --quiet S:/Internal > Internal.dump
svnadmin dump --deltas --quiet S:/Restricted > Restricted.dump
net start VisualSVNServer >nul 2>&1
for %%I in (S:\authz S:\authz-windows S:\htpasswd C:\INTERNAL\SVN\Backup.bat) do copy %%I . >nul
copy "%VISUALSVN_SERVER%\certs\*" certs >nul
copy "%VISUALSVN_SERVER%\conf\*" conf >nul
"%ProgramFiles%\7-Zip\7z.exe" a -mx9 %bdate%_%btime%.7z * >nul 2>&1
move 2*.7z C:\Users\DB\Dropbox\Backups\SVN >nul
cd ..
rd /s /q svnbackup >nul 2>&1
exit
\$\endgroup\$
10
  • \$\begingroup\$ For starters you could remove all unnecessary code. \$\endgroup\$
    – BDM
    Mar 18, 2013 at 6:41
  • \$\begingroup\$ @ProfPickle Such as? If you're referring to the first 12 lines, these take <1s to run. Otherwise I don't know what you're referring to. \$\endgroup\$ Mar 18, 2013 at 6:41
  • \$\begingroup\$ Color, title, a majority of the echo commands... There's not a lot you can do to increase the speed of a batch file. \$\endgroup\$
    – BDM
    Mar 18, 2013 at 6:44
  • \$\begingroup\$ @ProfPickle I really don't mind waiting 100ms or however long it takes to run them lines... I'm looking at the bigger picture. I know 1 option is to use svn hotcopy, but I think it'd involve rewriting the majority of the script, and I don't know whether it would result in a speed increase? Related SO question: stackoverflow.com/q/33055/1563422 \$\endgroup\$ Mar 18, 2013 at 6:45
  • \$\begingroup\$ To be perfectly honest, the only thing that's going to increase the speed by any significant time is to choose another language. I know it's not the answer you're looking for but it's really a one way street here. \$\endgroup\$
    – BDM
    Mar 18, 2013 at 6:47

2 Answers 2

1
\$\begingroup\$

This isn't a great answer but I've found some tips to hopefully (not guaranteed) increase the speed of your batch files.

Load Batch Files on to a RAM Drive. Use a small-size RAM drive with small cluster sizes to preserve memory. Then place the RAM Drive batch directory at or near the start of your path statement. Your batch files will run much faster because they are always in memory. Automate the process by placing statements in your AUTOEXEC.bat to create a RAM drive and then a BATCH directory on that RAM Drive. Next have it copy the batch files to it.

Give Full Path names for all Commands. This allows DOS to go immediately to the directory required, thus saving a path search. So, as an example, if the MOVE command is to be used, issue it as "C:\DOS\MOVE..." rather than just "MOVE..." .

This method can also be extended to issuing full paths for the files on which actions are to take place. This means that a command will act upon only files on the stated drive and in the stated directory. This is good because if the batch file were to inadvertently be run in a wrong directory, unexpected things might

happen. Unintended files might even be deleted or modified. Directing DOS to the place where you want actions to occur, even if it is still within the current directory, is a wise and safe method.

Unfortunately those are the only tips I could find, and they probably aren't even worth it.

Sorry.

Source:
http://www.chebucto.ns.ca/~ak621/DOS/Bat-Tips.html

\$\endgroup\$
2
  • \$\begingroup\$ Thanks for the effort! Are paragraphs 2 onwards still relevant? It mentions DOS a few times... also, what's the source for this? \$\endgroup\$ Mar 18, 2013 at 7:03
  • \$\begingroup\$ The source seems pretty old (it has that musky smell). That's why I added the disclaimer "hopefully", because generally modern computers don't care if you use direct paths or not. \$\endgroup\$
    – BDM
    Mar 18, 2013 at 7:44
1
\$\begingroup\$

I'm afraid, you can't get reasonable speed change in your case:

  • I think, most time your bat-file perform svnadmin dump, where you have minimal amount of possibilities to change anything (except testing changing from --deltas to incremental|revision-range dumps)
  • You can think about changing backup-strategy: use svnsync or backup repositories as ordinary directories and additional files
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.