This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 5/20/2013 7:53 AM, Fedin Pavel wrote:
Hello!Heh... So, complete emulation would cost a major performance drop, right ? Well... Can there be any setting which enables these checks ? Atleast we have one use case...Not without lots of new code.So, maybe next Thursday?By the way, you said it would be slow... I have an idea how to implement a compromise solution which would not be horribly slow. What if we check existence of intermediate paths not every time but only when we meet thing like '..' ? I'll explain... For example, if we would access /foo/bar/baz, testing for /foo and /foo/bar existence would supposedly be a waste of time, because we would get "Object not found" on the final path too. But, when processing thing like /foo/bar/../baz, we really need to check for intermediate dirs. But, still not every time. In this example we actually need to test only for /foo/bar's existence. I. e. a path to which we apply '..', before stripping the last component. Does it make sense ?
Sure, that makes some sense. It might help address the concern of not adding lots of new code and minimize the slowdown that the code would add. But there is a clear reticence to fiddle with the path processing code because of its complexity already and its high use. Even what seems like a small slowdown can be magnified because it is called so often. Small changes adding new features can add allot of complexity once all the corner cases are cleaned up (your case is a one known example of such a corner case). So the message is not that folks here don't see the value in your suggestion or need help figuring out how to minimize the impact. What's needed is some code to do this and some good analysis that shows that it doesn't impact performance outside this corner case. Such a patch could then be evaluated directly for any complexity it adds and the performance analysis could be used to objectively evaluate any impact there. Not to discourage you but there will be a fairly low tolerance for much of a complexity change or almost any performance degradation. Cygwin's performance is a regular source of complaints on this list (and elsewhere). There's a difficult balancing act in this code so changes are not undertaken lightly. Just fair warning. :-) -- Larry _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |