The benchmark timings do depend on this number, so they really only means something when printed with the number of watched items. At least when the number is correct, so if I remove it here I'll have to find another way to obtain the info in the follow-up patch.

IMHO this is all the more true if the improved algorithm refrains from watching folders that are filtered out because that means you cannot even do a simple find foo -type d | wc -l to determine the number of directories under foo.

Actually, I could already introduce the ProjectWatcher class (it no longer needs a mutex), with or without the bit that applies the project filter. That should make the number of watched items available in the benchmark via dynamic_cast<ProjectWatcher*>(m_manager->projectWatcher(m_project)). Not watching likely filter suspects like .git and build should reduce import times a bit already so I like the idea, let me know if that's acceptable?

Can you please explain how that would work without creating a ProjectController instance in the benchmark?
I do get a non-null result from projectController() in the benchmark app but when I get a crash when I do emit projectController()->projectClosing(m_project). I don't understand why, the only explanation that makes sense to me is that the method returns an uninitialised IProjectController pointer.
The signal could also be sent from the Project instance itself rather than from the ProjectController.

Is there no other way to call this hidden code without patching code that's otherwise completely unrelated to dirwatching issues?

PLEASE don't just look at the patch, *try* it locally, look at the numbers you get with the most relevant KDirWatch methods and decide whether or not the time spent deleting dirwatchers is really irrelevant to you.

I honestly don't really understand why AFMP couldn't have a (protected) method that basically does the opposite of what the import method does.