On Mon, Jun 30, 2014 at 6:21 PM, Ivan Zhakov <i...@visualsvn.com> wrote: > On 30 June 2014 18:51, Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> wrote: >> On Mon, Jun 30, 2014 at 4:06 PM, Ivan Zhakov <i...@visualsvn.com> wrote: >>> >>> On 19 June 2014 14:21, Ivan Zhakov <i...@visualsvn.com> wrote: >>> > Hi, >>> > >>> > I've performed several FSFS performace tests using latest Subversion >>> > from trunk@r1602928. >>> > >>> I've re-ran my FSFS performance tests with trunk@r1605444 using latest >>> fsfs7 performance fixes including combining indexes to revision files. >> >> > [..] > >> Also, it seems that some of these tests are run from hot >> caches - causing a lot of variation and making comparison >> pointless. An extreme case: >> >> ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/ >> Copyright(C) 2002, Jem Berkes <jber...@pc-tools.net> >> >> === "svn log http://localhost/svn/ruby-fsfs6-unpacked >nul" === >> >> Execution time: 216.064 s >> ... >> Execution time: 13.268 s >> ... >> Execution time: 18.061 s >> > Yes, I use hot caches and already noted this in my report: "Every test > was run 3 times and only two latest used" > > I don't see the reason to test on cold disk caches because I assume > that caches in the real servers are somewhat hot. No matter how it's > complex to compare the results on hot disk caches. For me, log > addressing feature is definitely useless if it slower on hot disk > caches.
Innocent bystander's opinion: I appreciate your critical look at the performance of fsfs7, Ivan, but I disagree. I think in lots of real-world cases cold cache performance is much more important than hot cache performance. Especially in a big / busy repository and for use cases such as "svn log". I usually don't ask the same "svn log" three times in a row. User A might request "svn log" of some file or subtree, user B then asks for another subtree, and so on. It's the performance of that first (and usually only) request that matters most to me. Same for export: different users export different parts of the repository all the time. Not the same part a couple of times in a row (except perhaps right after some release / milestone / ...). So I for one am more interested in cold-cache performance improvements, even if they come at a (hopefully small) hot-cache performance cost. OTOH, I do wonder about these (hot-cache) performance regressions ... maybe they can still be improved? -- Johan
