|
Actually, I probably didn't replicate what you were describing very completely. I didn't let the Process Files step complete (I didn't let the step finish loading the list of files and iterate over them). During the iteration stage of execution of a Process Files step, my CPU did peg at 100%.
Obviously the first stage of the Process Files action is disk-intensive and consequently does not use a high percentage of CPU cycles (because typically it is waiting on the disk). Once this stage of execution is complete, it then iterates over this list of files (in memory at this point) which becomes a CPU intensive operation.
Any running application requesting CPU cycles will be given any idle cycles (hence CPU usage will typically be 100% in this scenario). If multiple apps request CPU time, then any available cycles will be time-shared between the these apps. This is normal behaviour and should be expected.
During my test, the system did not stop being responsive even though the CPU usage was at 100% (because Visual Build Pro was not hogging resources and was only using CPU time that was not needed by any other process).
For an application to use less than the available cpu cycles when needed would be an non-standard throttling of application performance (for any application). Unless you are seeing system non-responsiveness during this test I believe what you are seeing is normal.
Of course, if a child step of the Process Files step is hogging resources than that is an entirely different matter (a compiler, for example).
|