scala-native
javalib Files#walkFileTree method has mutiple opportunities for improvement
The javalib Files#walkFileTree offers multiple opportunities for improvement (aka defects).
I am doing my best to avoid a philippic.
When the dust settles on walkFileTree, the corresponding walk method should be examined
for similar opportunities.
A non-comprehensive list:
-
[ ] The way that SN calls postVisitDirectory() does not match JVM. In current code, lll the calls are done after the last element of the walk is processed. JVM follows the more expected "preVisitDirectory, visitDirectory, postVisitDirectory".
-
[ ] Issue #3744
-
[ ] Issue #3879 Possibly hidden, but not fixed, by PR #3889.
-
[ ] Pessimal algorithmic & runtime performance. At least:
-
[ ] Testing for same attributes more than once. The tests go all the way out to the file system on each call. The JVM doc describes doing the much more reasonable one
readAttributes()to all the attributes likely to be used at once. -
[ ] Currently creating a directory contents stream sits atop algorithmic cost, particularly for large directories. The access is not lazy. FileHelpers.list(Path): creates an array which is then converted to a stream. Every item is touched even if SKIP_SIBLINGS happens. This approach eased initial implementation but can be improved by the code light of day.
-
-
[ ] code complex far beyond necessity or confidence.
