[GitHub] [commons-io] sebbASF commented on pull request #118: [IO-670] refine IOUtils.contentEquals(Reader, Reader)
sebbASF commented on pull request #118: URL: https://github.com/apache/commons-io/pull/118#issuecomment-669154882 Do you have any proof that using UnsyncBufferedReader etc in contentEquals will result in a slow-down unless further changes are made to contentEquals? If so, what further changes are needed to contentEquals, and what is the speed improvement? As to any renaming, that can be done later. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] sebbASF commented on pull request #118: [IO-670] refine IOUtils.contentEquals(Reader, Reader)
sebbASF commented on pull request #118: URL: https://github.com/apache/commons-io/pull/118#issuecomment-669139532 Undynchronized should presumably be Unsynchronized? However, I think that makes the class names rather long. I think Unsync is clear enough as a prefix (and avoids the issue of whether to use -ized or -ised) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] sebbASF commented on pull request #118: [IO-670] refine IOUtils.contentEquals(Reader, Reader)
sebbASF commented on pull request #118: URL: https://github.com/apache/commons-io/pull/118#issuecomment-669097163 AFAICT the new classes UnsyncBufferedReader etc are not actually used (except in test code). I would expect all the contentEquals methods to remain exactly the same except for changes to the input sources. The logic should remain unchanged (otherwise the new classes are not proper replacements). Likewise I would not expect to see any changes to test cases, only new ones for the new classes, and perhaps a few new samples for existing methods where the coverage is incomplete. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] sebbASF commented on pull request #118: [IO-670] refine IOUtils.contentEquals(Reader, Reader)
sebbASF commented on pull request #118: URL: https://github.com/apache/commons-io/pull/118#issuecomment-668293267 The original comparison methods are easy to follow. It would be good to keep the same clarity by defining new versions of BufferedReader that have good single-threaded performance. Such classes would also be useful elsewhere. So for example BufferedReader bufferedInput1 = toBufferedReader(input1); would become something like: FastBufferedReader bufferedInput1 = toFastBuffer(input1) (*) where toFastBuffer() works like buffer() but returns an instance of a non-threadsafe FastBufferedReader. The FastBufferedxxx classes would also be useful in their own right elsewhere in IO. Obviously the documentation would need to make it clear that they are not thread-safe. I suspect they don't need to implement mark (which would make them simpler). (*) FastBuffer is just a suggestion for the name. Maybe QandDBuffer would be better (Quick and Dirty)! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] sebbASF commented on pull request #118: [IO-670] refine IOUtils.contentEquals(Reader, Reader)
sebbASF commented on pull request #118: URL: https://github.com/apache/commons-io/pull/118#issuecomment-665587079 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
