Hoi Jos,

>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.

Of course. it is impossible to have any final judgement without seeing the actual code.

>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.

What I was trying to say is that the numbers of fields is the sole factor for each variable reference evaluated.

>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.

I agree

>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."

Sure, However, I like to point out (for the lurkers) that often there is something that is way more time consuming than the ommision of mdot. If you are doing for example database access, or (complex) graphical output, you may find that the time consumed by those statements make the omission of mdot.


Walter,