This issue has already been reported to our developers and will be fixed as soon as possible. If you'd like to assist, you can send us a sample (a snapshot) of Path Finder process in a separate file - this will enable us to analyze what happens with the application. Here's how to get it:
Open Path Finder and reproduce the problem.
Open Activity Monitor from the /Applications/Utilities folder.
Select Path Finder in the process list. To help making a selection, type "Path Finder" in the Filter field.
Click the Sample Process button in the toolbar - this will open a new window entitled "Sample of Path Finder" and a sample of the process is collected.
Click Save and save the sample file.
Close (Command-W) the Sample window opened in step 2.
Send the sample file saved in step 5 to us.
Be sure to let us know should you have any further questions.
Same problem here. SpinDump and SampleFiles attached. I'm sending several to help with changes over time.
Secondly, one process associated with PF is "opendirectoryd". I've attached a Sample file showing the contribution this process is making to the problem in this thread - initiated by opening a new directory in PF.
Also, I've attached a file showing PF persisting as a resource-hungry process AFTER quitting PF.
Using PF7.6.1 (1726) and macOS 10.13 (17A405).
PS: Having exact same problem on my iMac running macOS 10.13.1 beta3 (just released Dev)
I am facing exactly the same problem as described by vincent.boudry.
PF 7.6.2 (1729)
MacBookPro Retina 15.4' mid 2015 with AMD Radeon R9...
I always have to Quit PF to get rid of coreservicesd & PF processor hogging.
Hey guys, I just turned PF off. That eliminated the 95% CPU use that it was causing in coreservicesd (the daemon) and its own line item in ActivityMonitor.
I hope you can resolve this. Very disappointing. I have been sitting here in a very important trial frying eggs on my MB Pro and seeing the power get sucked out of it. It's taken me a bit to figure this out.
You would have saved me a lot of time if you have given me, along with other customers, the courtesy of an email when you figured out that you and we have this problem.
Interestingly, I'm not seeing major CPU upticks with PF, but am seeing significant memory use that, when high enough, pretty much stops my MBP. Right now after moderate use it's sitting at 1.7 GB of RAM, but I've seen it as much as 17 GB. I have 8 GB of physical RAM. As a result, I end up periodically quitting PF.
The very sad fo...
on 11 Dec, 2017 12:50 PM
Same problem here. PathFinder (and Coreserviced) up to 60-80% CPU ALL THE TIME.... Reported to Cocoatech several times (Jan+Feb with Sierra, September+October with High Sierra). No improvements up to now :(
"Kind of" same problem is back with PF8 (8.0.1, 1867): PF + coreserviced takes ~100%. (coreserviced immediately goes to ~0 when PF is stopped). The noticeable difference is that the PCU overload stops by itself after ~5–10 mins.
Here are sample and spindump files taken during the high CPU period.
Path Finder Support Team closed this discussion
on 07 Jun, 2018 06:25 PM.
Path Finder Support Team re-opened this discussion
on 07 Jun, 2018 06:25 PM
on 08 Jun, 2018 08:53 AM
I am also having high CPU usage of Path Finder 7.6.2 in High Sierra (just upgraded). It runs almost constantly at 50 - 90%, regardless of whether I am using it or not.
Attached is a sample of the Path Finder process.
I would upgrade to 8 but you don't have the Shelf module available yet (not that you make it clear on your website that you have removed this feature from PF8 that were available in PF7 - I had to find out by trying it and spending my time finding it was not suitable for my needs).
I’m not having that issue at all re: CPU in PF8. You really should consider upgrading since I would suspect PF 7 is done. Modules work well and I guess it comes down to whether you want stability or a shelf.
@dtoub 'Modules work well' ? Not for me to be honest. I'd much rather have the hide/show flexibility of shelves and a browser layout I can rely on (still no responses to my requests on how to successfully achieve this). PF7 gives me this and I'm not seeing anything concrete in the Cocoatech responses in the forum that makes me hopeful PF8 is ever going to be usable for me.
I'm experiencing this issue too, and for me it seems to be related to the "show all sizes" option.
For me, there are two options at play here:
1. how long it takes PF to get I know that DaisyDisk can scan a hard drive and get all directory sizes incredibly quickly -- much faster than, for example, a "find" command (or getting sizes in PF).
2. It feels like the issue is related to viewing a folder, and then moving to another folder while it's calculating sizes for the first folder. Almost like there is a size-calculating-thread that doesn't get terminated when folder changes in PF.
Regardless, I have 12 days left on my PF evaluation before I must upgrade. And I certainly don't want to upgrade while PF is misbehaving like this.