same command, very different durations

If two runs of the same command have very different durations, wouldn't you expect very different logical reads?

----

OK, the first question is why two runs of the same command should be different at all.

We now have on this server lots of RAM, PLE is stuck up over 10,000, and virtually no blocking per wait stats.

Whether an SP with parameter sniffing or dynamic SQL (and these are mostly SPs), the very same command should run in about the same time, right?  Yet we have lots of cases where the runtimes are 10x or more different.  I'm trying to understand why.

For the most part, reads are the same between runs, but CPU varies widely, corresponding pretty much to the duration.

I don't understand that.

We have four cores in production and set to maxdop=1.

The server should be nicely "warmed up" after a restart many hours ago, so most plans should already be cached.

----

So where reads don't much vary, where would this large variability in cpu and duration be coming from?

SQL 2008 R2 in production, running on VMWare.

Thanks.

Josh

ps - if you have a nice profiler trace table of your own, try this:

select
  SUBSTRING(textdata,1,16000) as cmd,
  MAX(datalength(textdata)) as cmdlen,
  COUNT(*) as cnt,
  SUM(duration/1000) as sumdur,
  AVG(duration/1000) as avgdur,
  MIN(duration/1000) as mindur,
  MAX(duration/1000) as maxdur,
  cast(1.0 * MAX(duration/1000) / min(duration/1000) as decimal(6,2)) as [dur variation],
  MIN(reads) as minreads,
  MAX(reads) as maxreads,
  cast(1.0 * MAX(reads) / min(reads) as decimal(6,2)) as [reads variation],
  MIN(cpu) as mincpu,
  MAX(cpu) as maxcpu
from dbo.trace_prod_20130219a_100ms
where textdata is not null
  and reads > 1000
group by SUBSTRING(textdata,1,16000)
having COUNT(*)>1
order by 8 desc;