Re: [TSVN] Another go at a patch for SVNFolderStatus

Will Dean wrote:

> I was thinking that in fillstatusmap, you would convert from / to \
> before putting the item into the cache. (In the if (path) {} ) bit near
> the bottom of the function.
>
> That way, the cache would contain '\' paths rather than '/' paths, and
> you wouldn't need to do the conversion for a cache hit, only when
> loading the cache.

/me thinking that you're right.

> BuildCache would cope with '\' paths already, bar the const TCHAR * p
> = _tcsrchr(filepath, '/'); line, which would need to check for a '\'.
> , so it wouldn't mind. (You might also need to look at the m_cache.find
> at the bottom, to check that it still made sense, though I think it does.)
>
> But I don't *really* think that the \ to / conversion is an important
> factor in performance! If it didn't make the code any more complex
> (just moved the conversion from one place to another), then it might not
> be a bad thing. Every microsecond we can avoid stealing from the shell
> seems worthwhile.

I'll have a look at that this weekend. We have to be very careful with
'\' and '/' because Windows likes '\', but Subversion _only_ knows '/'
(Windows API's usually can deal with both, not all though).

> It's a pity that it's so difficult to profile the shell extension - do
> you have any kind of test-harness which can host it 'standalone', and
> submit some kind of test workload?

No, I don't have such a testsuite. If I had one, you wouldn't find so
many performance optimizations ;)

> I'm going to turn my attention to SVN shortly - I think there might be
> some *very* low-hanging fruit there in terms of performance,
> particularly on large files. apr_file_copy, running on Win32, copies
> files in 512 (!) byte chunks, which is just crazy.

I only deal with the Subversion API and leave the apr stuff to that. I
once had a look at apr, but I couldn't get used to it...
Don't know if you can get apr to change though - the guys over there are
sometimes more picky about changes than the Subversion people (even
though many work on both projects).

> We have a 2-gig working copy, with many, many files between 1M and 2M in
> size, and frankly some aspects of SVN performance are not that brilliant...

Subversion as well as apr are optimized for smaller files. Apr is
because it's an Apache project and for a webserver, the files are
usually very small. Subversion is because it uses apr...

2gigs? What are you storing in there?
/me wondering how big your repository already is and if such big
harddrives even exist?

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org