Re: [RFC] i18n.pathencoding

["Torsten Bögershausen" <tboegi@web.de>]

On 04.09.12 22:12, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@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.