Closed eed3si9n closed 6 years ago
Lets try the smaller & faster approach - speed was the original target anyway It seems surprising that is changes the behaviour but it will not be the first or last time that I am surprised this week.
I ran into NoSuchFileException
with the Files.walk(rootPath)
, so we still need to hand roll the visitor, but I think I'm going to try a hybrid approach.
On Windows on VirtualBox, the original implementation seems to be the fastest:
old delete 1 took 2714.851 ms
delete #135 1 took 3623.421 ms
delete #170 1 took 2850.538 ms
old delete 2 took 2716.804 ms
delete #135 2 took 3732.995 ms
delete #170 2 took 2819.38 ms
old delete 3 took 2747.379 ms
delete #135 3 took 3769.503 ms
delete #170 3 took 2888.485 ms
old delete 4 took 2737.943 ms
delete #135 4 took 3727.32 ms
delete #170 4 took 2889.788 ms
old delete 5 took 2828.599 ms
delete #135 5 took 3677.875 ms
delete #170 5 took 2863.272 ms
steps
On Windows,
testOnly testpkg.ServerSpec
using IO 1.2.0-M1.problem
notes
Using IO 1.1.10 fixes the issue, so something in https://github.com/sbt/io/pull/133 / https://github.com/sbt/io/pull/135 is making IO.delete more sensitive to "The process cannot access the file because it is being used by another process."
We can revert the PR or try something else like https://stackoverflow.com/a/35989142/3827, which also is supposedly is faster than the visitor approach.
/cc @mkeskells, @cunei