Identify the real process

An application can contain several helpers. The visible app name may not match the process consuming CPU or holding a file. A browser is the obvious example: one window, but a main process plus a renderer helper per tab group, a GPU helper, and a networking helper. When “the browser is slow”, the question is which of those processes is slow.

Find the candidate, then verify it

Start with Activity Monitor or ps. Activity Monitor’s CPU tab sorted by % CPU gives you a name and a PID fast. In Activity Monitor you can also double-click the process and check the Open Files and Ports tab.

Then inspect one PID from the shell:

ps -p 1234 -o pid,ppid,user,%cpu,%mem,etime,command

Replace 1234 with the observed PID. Read each field with intent: USER tells you whose session owns it, ETIME says how long it has been alive (a process born seconds ago is a different suspect than one running for days), and COMMAND shows the full executable path. The path is the identity check — a helper inside /Applications/Slack.app/Contents/Frameworks belongs to Slack no matter what its short name says.

Check what it holds open

lsof -p 1234 | head

The first lines show the working directory (cwd), the executable itself (txt), and then open files, sockets, and devices. If a process “won’t let go” of a file or a port, this is where you see it, with the exact path in the NAME column.

Confirm before acting

Confirm ownership and purpose before quitting or signaling it. Killing a helper often just makes the parent respawn it, and killing the wrong node takes down someone else’s work.

One trap: PIDs are reused, so recheck immediately before acting. A PID you wrote down ten minutes ago can now belong to an entirely different process. Re-run the ps line, confirm the same command path, then act.