fs.Dir.deleteTree
optimizations and recursive implementation
#13070
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Opening this as a draft for feedback, as there are open questions here:
EDIT: See #13070 (comment).
See #13048 for more context. All benchmarking is done with the same folder structure mentioned here:
There are two separate/unrelated parts to this:
First, this eliminates some redundant
deleteFile
calls from the currentdeleteTree
implementation while not changing any functionality (see #13048 (comment) and the commit message in the list below for more info). This leads to a decent reduction in syscalls but a pretty insignificant decrease in wallclock time.Before:
After:
(note also that the
lseek
syscalls are also gone; this is via the introduction ofIterableDir.iterateAssumeFirstIteration
which the recursive implementation also takes advantage of)Benchmark results:
Second, this adds a more performant version of
deleteTree
that uses recursion. This version ends up beatingrm -rf
on my system.Recursive version:
(note that without
IterableDir.iterateAssumeFirstIteration
, there would also be 4863 lseek calls here but they also wouldn't affect performance too much [strace says they are 2% of the time taken in the version with the lseek calls])rm -rf
:Benchmark results: