frequency of reading process times & read process times without pid

[ashsifat]

I have two questions:

what is the maximum frequency of data collection using psutil.cpu_times() ?

how can I use psutil.cpu_times() without specifying pid everytime I run it as I need to read cpu times and percentage for a sincle process. Currently I use it like this but I need to change the pid everytime I run the process of interest as it keeps changing with each startup.
p = psutil.Process(<pid_number>)
times=p.cpu_times()

[giampaolo]

what is the maximum frequency of data collection using psutil.cpu_times() ?

Not sure what you mean.

how can I use psutil.cpu_times() without specifying pid everytime I run it as I need to read cpu times and percentage for a sincle process.

Again, not sure what you mean. If the PID changes every time you have to instantiate a new process instance.

[ashsifat]

Rephrasing first question, in what frequency is the execution time recording recommended and does it have a high overhead on the processor to run this function?

Rephrasing the second question, Can I record cpu_times() of a process using the process name somehow instead of the pid?

[giampaolo]

Rephrasing first question, in what frequency is the execution time recording recommended

I'm not sure what you mean but everything I know about cpu_freq() is written here, really:
https://psutil.readthedocs.io/en/latest/#psutil.cpu_freq

does it have a high overhead on the processor to run this function?

No.

Can I record cpu_times() of a process using the process name somehow instead of the pid?

Search the process by name first:
https://psutil.readthedocs.io/en/latest/#psutil.process_iter
https://psutil.readthedocs.io/en/latest/#filtering-and-sorting-processes

[ashsifat]

Okay, Thanks for the answer. I understand the second one perfectly now.

What I was trying to say in the first one is,

Is running the function "cpu_times()" periodically on a python script going to consume a significant amount of cpu-resources? I am guessing from your previous answer that it is not.