Philip Martin wrote:
> SteveKing <steveking@gmx.ch> writes:
>
>
>>But what about having the filestat information in the svn_wc_entry_t
>>struct returned by svn_client_status()?
>
>
> apr_finfo_t is 84 bytes on a 32-bit machine, that would be quite a
> large increase in the size of svn_wc_entry_t which is currently 124
> bytes. (I see we still have all the new lock stuff in svn_wc_entry_t,
> didn't we agree to drop everything but the lock token?)
>
> Perhaps we could put it into svn_wc_status2_t?
124 bytes? That can't be right. Maybe the sizeof() is 124 bytes, but the
whole struct is much larger already. There are several entries which are
strings (name, url, uuid, ...). So I don't think another entry
apr_finfo_t * fileinfo
would increase the size of that struct that much.
>>That would help TSVN a lot (performance wise) - I guess you know
>>that Windows isn't as fast with those calls as Linux, there were
>>some reports before about timing of 'svn st' and 'svn ci' for Linux
>>and Windows on this list...
>
> I find it odd that one more stat call would make that much difference,
> because svn_client_status itself is so ineffecient. It stats each
> versioned file 5 times, with a further 7 stats on the properties
> files. Plus it reads the entire working properties file for each
> versioned file. Does it really matter if TSVN makes one more stat?
Every filestat call matters. Basically, you can assume that the time an
svn_client_status2() call takes is spent by file access. The little time
the function needs for calculating stuff doesn't matter much, and that
time get's smaller with faster processors. But the time for file
accesses can't be made faster with faster processors.
So, the 13 stats for svn_client_status() plus one TSVN would need:
that's an increase of 7%!
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 13 22:46:34 2005