On 04.09.12 22:12, Junio C Hamano wrote:
> Torsten Bögershausen <tbo...@web.de> writes:
>> This leads to 2 questions:
>> a) Do we want the reencode feature in git, so that I continue to work on it?
>>    From a performance point of view that would probably OK:
>>    The "git status" on a linux tree was slightly slower on my PC when 
>> measured with time.
>>    From the user experience there was not a difference.
> I am not fundamentally opposed to such a change, as long as the
> change does not affect performance at all when the feature is not
> used, and the resulting code does not become too ugly.
> Use of the "reencode" feature may have to make things slow, but you
> have to spend some cycle to do what the feature has to do anyway,
> so...
>> b) If yes,
>>    I have to admit that I don't use paths from --stdin or file so much,
>>    except "git am" or "git format-patch"
>>    Which commands are affected?
> $ git grep -l -e '--stdin' Documentation/git*
> may be a good starting point.

I'll have a look into the --stdin stuff later, thanks Junio

And here some benchmarks on my PC,
first run is using git v1.7.12,
second run with i18n.pathencoding applied 
 for f in 1 2 3 4 5; do time git status  ; done 2>&1 | egrep "^user|^real|^sys"
real    0m0.492s
user    0m0.300s
sys     0m0.200s
real    0m0.448s
user    0m0.260s
sys     0m0.190s
real    0m0.443s
user    0m0.250s
sys     0m0.200s
real    0m0.451s
user    0m0.260s
sys     0m0.190s
real    0m0.429s
user    0m0.230s
sys     0m0.200s
for f in 1 2 3 4 5; do time ~/projects/git/tb.localfname/git status  ; done 
2>&1 | egrep "^user|^real|^sys"
real    0m0.580s
user    0m0.320s
sys     0m0.230s
real    0m0.461s
user    0m0.260s
sys     0m0.200s
real    0m0.463s
user    0m0.250s
sys     0m0.220s
real    0m0.445s
user    0m0.290s
sys     0m0.160s
real    0m0.443s
user    0m0.240s
sys     0m0.210s

It seems that we have a little penalty on performance.
I'll have a look at the readdir() function.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to