Hi Jos,

I think you've hit one circumstance where it differs from a performance point of view.
However, the performance difference is related to the number of fields in the currently active workarea. Now I see you mention that you read from a 100 field table here, that is constructed out of a 10 field table. Now of course If don't know your program here, but seem to have an intermediate step in here by doing the datamunging.

Most likely, if you are doing your graphs inmediately from your 10 field table or cursor, things would speed up significantly as well. Since the mdot performance difference is related to the number of fields, the usage of mdot would not be as significant in this case.

IOW, if really was looking into a permance boost, I would look into ways of changing the algorithm.

If you are using a lot of memory variables to do the calculations, then I certainly can imagine the boost to be significant. For example, If were to construct a sales line graph grouped by month I could of course do something like.

SELECT Statdata
FOR nT = 1 to 12
    xPos = nT * xScale
    yVal = 0
    SCAN
       yVal = yVal + SomeCalculation()
    ENDSCAN
    yPos = yVal * yScale
    THIS.DrawGraphPoint(xPos, yPos)
ENDFOR<PRE>

IOW, if you are SCANNING through the table and access each and every field in a memory variable then you indeed are benfitting from mdot.

Another way of doing this is use the database engine more intensively.

<PRE>SELECT MONTH(date), as month SomeCalculation(...,...) as Yval, ...., ....
    FROM StatData ;
    GROUP BY Month, ...., ....
    INTO CURSOR GraphData

SCAN
    THIS.DrawGraphPoint(Statdata.Month * xScale, StatVal.YVal * yScal)
ENDSCAN

This would significantly reduce the number of variables referenced. Most calculations are done directly one the fields and a not loaded into memory variables until needed. Here mdot would not give you any significant performance advantage.

Walter,


>Well I used to be in the camp where I did not use mdot at all (forgive me Fabio :) and believed that mdot would not make a significant difference to performance. I always use field and variable naming conventions to avoid field/variable conflicts and have never had a problem with that issue, ever.

>However, the recent discussion on mdot and having some free time on my hands <g> made me spend a few hours reworking some intense processing code:

>Background:

>1) I have one app which draws charts of various data. The chart data is stored in a file of about 10 fields. This data is read into a temporary cursor where several manipulations can be performed on it. The data points for a chart can easily have 1000, 5000, or more points.

>2) The temporary cursor can then be further processed in order to calculate other data from the original data points. This requires working through the cursor, sometimes more than once.

>3) Therefore a temp data cursor of 100 fields and 1000 records of data points and being processed for further calculations involving easily 20, 30, or more variables works out to 100f x 1000r x 30v = 3,000,000 field/variable lookups. Hence my original question.

>I changed all this code to use mdot. The result is that charts that took 1 to 2 seconds to draw are now drawing in as little as half the time. The use of mdot in these charting routines has resulted in a speed improvement of between 30% and 100% depending on the complexity of the chart involved.
>
>Although in absolue terms it means only a 0.5 or 1.0 second improvement per chart the percentage improvement is fantastic. And when a user is drawing numerous charts, including charts that automatically refresh as new data arrives, this is a very signifcant improvement.
>
>My opinion; 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 :)
>
>PS: Fabio I appreciate your position that mdot is primarily a correct coding technique with secondary benefit being a potential speed improvement. But old habits die hard :)