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,
>> 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"
for f in 1 2 3 4 5; do time ~/projects/git/tb.localfname/git status ; done
2>&1 | egrep "^user|^real|^sys"
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