Profiler giving weird results

I'm running profiler in unix, and I'm getting some strange results for one line of my code. Basically it looks like this:

c=zeros(T,1);
for t=1:T
t0=clock;
ran=range(x{t},1);
c(t,1)=etime(clock,t0);
end

I know I could use cellfun() above to speed it up, but in the real-world case 'x' is not a cell but a matrix which changes on every iteration. I've just simplified it for illustration here.

For your information, on every iteration, 'x' has 4 columns about 1,000,000 rows, with about half of the entries being NaN's. T (number of iterations) is about 10,000.

Now, the profiler tells me that the line using the range() command takes about 1,000 seconds in total (that's on average 0.1s per iteration). Since I didn't want to believe this, I put in the timer like in the illustration, and if I calculate 'sum(c,1)' after the loop finishes, I get about 100 seconds, or only one-tenth of what profiler tells me.

I've already dealt with the issue of using multiple CPU's by using taskset to set the number of CPU's to 1.

I somehow suspect that the time is spent somewhere other than that ominous line, since the range command shouldn't really take up so much time, but how can I be sure?

Thanks for everyone's help!

[Adam]

What result do you get if you put that timer around the whole for loop?

I've never used clock and etime, I always use tic toc for timing when I am not using the profiler, but I assume its results are similar. It may be that the etime line executes and then some further instruction related to the previously line happens - e.g. memory reallocation or something that will show up as being that line in the profiler, but when you add a clock in the offending time happens after the call to the etime function.