On 07/18/2013 07:32 PM, Junio C Hamano wrote:
Mark Levedahl <mleved...@gmail.com> writes:
Unlike the results on the fast Win7 laptop, the above show
statistically significant slow down from the fast_lstat approach. I'm
just not seeing a case for the special case handling, and of course
Junio has already voted with his preference of removing the special
case stuff as well.
Please don't take what I said as any "vote" in this thread. I do
not have a first-hand data to back anything up.
I was primarily trying to see my understanding of the consensus of
the thread was correct. If we can do without s/lstat/fast_lstat/
almost everywhere in the codebase, of course, I would be happier, as
it would give us one less thing to worry about.
If the assumptions like "they were declining minority and only lose
population over time", "it is easy for them to revert the removal
and keep going", and "removal will not hurt them too much in the
first place, only a few hundred milliseconds", that might trump the
longer-term maintainability issue, and we may end up having to carry
that win32 stat implementation a bit longer until these users all
switch to Cygwin 1.7, but judging from the "cvs binary seems to be
built incorrectly" incident the other day, it might be the case some
users still hesitate to update, fearing that 1.7 series may not be
solid enough, perhaps?
I cannot say how many users of 1.5 exist. I see no evidence of 1.5 users
on the Cygwin lists, the developers noted a total of 14 downloads of the
1.5 installer in the year prior to removal of 1.5 from the mirrors. The
stated reason for keeping 1.5 available for four years after its
development stopped was support of older Windows variants (which
Microsoft dropped support of before Cygwin did, BTW). But, none of this
is conclusive about the current relevance of v 1.5.
The status as I understand things:
1) The existing schizophrenic stat on master is incompatible with the
new reference api on pu, therefore some change is required.
2) Ramsay has graciously provided two separate patches to address the
above, one reverting to use only of cygwin stat/lstat, one including a
fast_lstat that should provide better speed at the expense of POSIX
compliance.
3) We have conflicting reports about the speed of the second patch:
Ramsay shows a good speed up on Cygwin 1.5, with slight performance
regrets on MINGW, no change on Linux. I found no effect on a current
bare-metal Window 7 installation using Cygwin 1.7, but degradation on a
virtualized WinXP installation using Cygwin 1.7. Ramsay also showed a
significant performance difference between running from the git tree vs
being installed, I looked for this effect but failed to replicate it.
The maintenance argument between the two patches is clear, the
performance argument less so. Perhaps others can help clarify this.
Mark
--
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
