Ok… I posted about two hours ago. TT’s find tool has now identified just flipped over the 100K file mark. Woot. The native find command was done (about 543K files) before I typed up my last post. So what took like maybe TWO and a HALF MINUTES with “find” compared to TWO HOURS with TTs tool…and it’s just barely crossed the 20% threshold. “Coreservicesd” has been sucking up a core at 95- 99% for the last two hours. My system is otherwise idle showing only about 13% total CPU utilization. “Find Any File” is up to 253 MB consumed – slowly and steadily rising. The FILE produced by my “find” command which has identified the 543K files (full path of a file on each line) is 66 MB in size – and it never consumes more than 67% of a single core when running.
Thomas Tempelmann’s “Find and File” just completed and reported that it found the exact same number of files as the shell Find Operation. It is a nicely organized tool. 14 hours seems a bit long for a search though.
boah … 
In one of the OS updates Apple moved calls to old API’s into a daemon - this is why Coreservicesd consumes as much time as it does. The effect of this has been to make the use of old API’s slow down enormously. A google search for recent posts about “Coreservicesd” will give you some idea of the scope of the issue. We’re aware that folderitem’s performance on APFS volumes is not the same as it was with HFS+ volumes and are working to address the issue.