When developing x264pro for PPro/AME I came across this bottleneck - ie not seeing 100% cpu load.
So...I did a test - I made a dummy encoder that simply dropped the raw uncompressed frame on the floor (not even to disk). This test showed how fast AME/PProHeadless can serve up frames. It's no-where near 100% loadon all cores on a quad or higher core computer. Therefore there are bottlenecks. My test used a static synthetic video frame so that removed harddisk delay from the equation since there was no source footage from disk. The delay is the processing within AME.
The reality is that AME via direct file or via PProHeadless is relatively slow at creating the raw uncompressed frames to hand off to the encoder. (They are called Exporters internally).
If the Exporter is doing a compression scheme that is hard on the cpu (eg h.264) it will gobble up all the remaining cpu potential. Thus you'll see 100% on all CPUs.
If the Exporter was written properly, in parallel with the compression (ie "encoding"), AME/PPro is creating (ie "rendering") the next frame using a 1 or more cpu cores.
If the export is a complex compression scheme by the time it finishes encoding that frame, AME/PPro will have already finished making the next uncompressed frame. That's a good thing because there is no wasted time since the compression gobbled up the cpu when the next raw frame was finished and Adobe sat around doing nothing.
On the flip side...
If you're exporting with a simple compression scheme, eg DV, MJPG, MPEG-Intra the exporter will have to twiddle its thumbs waiting for the next frame. It's these times you see all the delays in the creation of the raw rendered uncompressed frame.
Yes, hard disk speed and available memory will shorten the delays in making a raw frame but the reality is that for some codecs it's just not practical to render the raw frame & encode it using 100% of the CPU potential.
conclusion:
1: just because you're at 100% on all cpus doesn't mean that you're doing good. You could simply have a poorly implemented [complex] encoder.
2: just because you're not at 100% doesn't mean that it's hard disk or memory. It could just be the necessary time the AME needs to render an uncompressed frame.
If #2 is your problem narrow down the reason. For example, If you re-size your output in AME from a Imported File then the resize is done on the CPUs. If you drop that same file in a sequence of the same size and frame rate then Queue export from PPro to AME you then have the Mercury Playback Engine at your disposal. The MPE is 10x faster at doing the resize vs a multi-core CPU. - So.... if you're going to resize, put the darn thing in a seqeunce and queue it!
'hope that helps.
