Hi Walter,

Suffice it to say that the charting routines are very significantly more complicated than your examples below. It is not possible to do the graph directly from the table of source date. There are many calculations that need to be done which can fill some/all the other fields in the charts data cursor.

I have refactored these routines numerous times over the last few years and have speed time tests in all the various parts of the process. All parts of the charting routines that involve processing data points in order to calculate derived data improved significantly, much to my surprise.

Also, it is not how many fields in the current table that is the sole factor. It is the number_of_fields x number_of_variables x number_of_loops that must be looked at.

I do not think you need to find circumstances where mdot may not improve the situation. This misses the point imo. I provide a real world example of a commercial app which has improved processing speed by between 30% and 100%. That one can find an example of where it would not improve performance does not prove whether to use it or not.

Like I said in the conclusion of my post: "if you have loop code where the number of fields times the number of records being processed times the number of variables in the loop can be a significant number then mdot is essential for speed if nothing else."

Now that one has (I have) a definitive example of where to use mdot it makes more sense to always use it than to write code where sometimes it is used and other times not.

<snip>