On 21.06.2011 22:01, Johan Corveleyn wrote:
> 2011/6/21 Daniel Klíma<danklima_at_gmail.com>:
>> 2011/6/21 Johan Corveleyn<jcorvel_at_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_at_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.
Received on 2011-06-26 23:43:35 CEST