> [quit top-posting] Now you are my mom too?
> That's where you're wrong. Any patch you write that is technically > sound and shows a measurable improvement will most likely be accepted. Then you shouldn't have Cygwin's front line technical spokesman saying things such as: "If there was a way to make stat() faster why wouldn't it be in the source code already?" "Otherwise, I doubt that anyone outside of the cygwin developers understands the stat() code well enough to come up with a patch." "But providing a variant of stat() along the lines of what you propose above is not practical for all the reasons already stated." "I guess it's possible that someone just doesn't want to go through the pain of getting the patch accepted. In that case, everyone enjoy your private cygwin stat() patches." ------------ When I threw the idea out initially I asked for input from the people that have more experience in Cygwin than I do. I have been seeing these performance issues for years of using Cygwin. However, in the past week had some time to look at it. FWIW, because of the initial resistance I have been shown by the "front line developers." I have already contemplated of my own Cygwin branch. All that being said, I think the best solution is not to optimize the dll stat(), but to do it at the executable level. I see that Cygwin already has some level of patches at this level, it shouldn't be too difficult to support. Chris -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
