You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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".
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.
The text was updated successfully, but these errors were encountered:
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 correspondingwalk
method should be examinedfor 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 Files.walkFileTree does not throw FileSystemLoopException #3744
Issue
Files.walkFileTree
silently swallowsNoSuchFileException
#3879 Possibly hidden, but not fixed, by PR fix: javalib SimpleFileVisitor#visitFileFailed now matches JVM #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.
The text was updated successfully, but these errors were encountered: