On 21.06.2011 22:01, Johan Corveleyn wrote:
2011/6/21 Daniel Klíma<dankl...@gmail.com>:
2011/6/21 Johan Corveleyn<jcor...@gmail.com>:
Hi,
I managed to get the benchmark 'suite1' (tools/dev/benchmarks/suite1,
which is used for the automated benchmarks [svnbench] on svn-qavm)
running on Windows. I did that by translating the 'run' script (bash)
to a Windows "batch" script (I'm not much of a "batch" programmer, but
with some trial and error, and the help of google ;-) ...).
I've put the run.bat in attachment here (just strip the .txt
extension). I'll commit it tonight (don't have access right now), but
some extra eyes in the meantime can't hurt :-).
There is one annoying issue remaining with the run script for Windows
(or the benchmark in general): I get an error when running the 100x1
tests (100 directory levels deep). I reduced it to 50x1, but still get
the error. It's probably some "max path component" or "max path
length" limit on Windows/NTFS that's causing this. Maybe some of the
Windows-devs knows how to work around this? Or should I reduce that
test to 25x1?
...
File
"C:\research\svn\client_build\trunk\tools\dev\benchmarks\suite1\benchmark.py",
line 247, in create_tree
create_tree(dn, levels - 1, spread)
File
"C:\research\svn\client_build\trunk\tools\dev\benchmarks\suite1\benchmark.py",
line 240, in create_tree
f = open(fn, 'w')
IOError: [Errno 2] No such file or directory:
'c:\\docume~1\\user\\locals~1\\temp\\tmpmddeli\\wc\\trunk\\dir_2\\dir_4\\d
ir_6\\dir_8\\dir_10\\dir_12\\dir_14\\dir_16\\dir_18\\dir_20\\dir_22\\dir_24\\dir_26\\dir_28\\dir_30\\dir_32\\dir_34\\dir
_36\\dir_38\\dir_40\\dir_42\\dir_44\\dir_46\\dir_48\\dir_50\\dir_52\\dir_54\\dir_56\\dir_58\\file_59'
]]]
For the rest it runs fine. Below are some results (only the 5x5 and
1x100) from comparing trunk@1137727 with 1.6.17 (SlikSVN binary) on
Windows XP (32-bit) with local disk, with Antivirus disabled.
Note that it took a *huge* time to run, even without the 100x1 tests
(~ 7 hours). I guess that shows how slow my machine really is ;-),
especially with 1.6. The performance improvements are definitely great
though (especially 'update', which is 80% faster with trunk! And also
'commit', with is down almost 60%).
...
--
Johan
Hello.
Max_Path is 256 chars excluding drive part. Max path for unicode
version of API is 32,767 when using path with "\\?\" style. I think
cmd should be able to work with \\?\ .
Ref: http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx
(Naming Files, Paths, and Namespaces section: Maximum Path Length
Limitation)
Thanks, Daniel. That explains it.
But unfortunately, the error happens inside the python script
benchmark.py (in tools/dev/benchmarks/suite1), and I haven't found a
way to avoid it. I've experimented a bit with pre-pending the path
with "\\\\?\\" (which was also suggested at the end of this python
issue: [1]), but it didn't help.
I'll commit the Windows variant of the run script (run.bat) for now
with a maximum "levels" of 25, which means it usually won't exceed the
maximum path length. Maybe someone else can enhance it later (and/or
benchmark.py) to enable benchmarks for even deeper working copies on
Windows ...
Hi Johan,
To throw in my €0.02, I just want to make sure
you are aware that this benchmark is somewhat
"unfair" as it does not measure a simple client.
Instead, it uses ra_local (unless I'm completely
mistaken here).
The effect is two-fold: it does not show how an
up-to-date (1.7) client performs relative to an
older one (1.6) when using them against a 1.7
server, i.e. whether users might be better off *not*
to upgrade their clients.
Secondly, a number of performance improvements
concern the protocol handling (httpv2) or are limited
to "real" servers, e.g. caching. In other words, 1.6
is artificially slowed down compared to a realistic
setup and 1.7 is also denied a significant part of
its upgraded infrastructure.
-- Stefan^2.
