High CPU usage

[RichardHooijmaijers]

I tested the package on a windows 10 machine with Intel Core i5-13400T.
During these tests I noticed that the CPU usage was quite high, even when applied to a relatively small folder.
When having two instances of watcher I noticed that CPU usage was ~50%.

Not sure if there is anything that could be done within the package and maybe it is directly linked to ReadDirectoryChangesW?
I originally planned to have a few instances running, which might lead to problems (e.g. 4 instances uses almost all of my CPU).

No idea if it is helpful but the function recurse into a directory, could it help to have an option to not watch recursively?

[shikokuchuo]

Do you have a 'reprex' that reliably reproduces this for you? E.g. if you start with a clean directory, then add x number of files or y number of sub-directories? This will help narrow down the cause, so we can know where it makes sense to apply a fix.

I'm going to tag this as an issue for TDD 2025 where participants can have a go at diagnosing this.

[RichardHooijmaijers]

Did some additional testing and found out that it actually doesn't matter how many files/directories are present. I believe the main issue is when setting the latency argument. See below my findings on it:

testdir <- normalizePath(paste0(tempdir(),"/watcherTest"), winslash = "/")
dir.create(testdir)
# writeLines("test",paste0(testdir,"/file.txt"))

# No problem, CPU% is low 
w <- watcher::watcher(testdir, latency = 1)
w$start()
w$stop()

# Here we have a problem; CPU% is ~20%
w <- watcher::watcher(testdir, latency = 0.99)
w$start()
w$stop()

Hope this helps!

[shikokuchuo]

Thanks @RichardHooijmaijers. Apologies for not getting to this sooner - the re-diagnosis was a great help!

The issue was that on Windows, a value less than 1 was being incorrectly rounded down to zero due to a double/integer type mismatch in the C++ code. This is an issue with the upstream libfswatch library, which we will patch here anyway, and we'll also take it up with upstream.