Discrepancy in execution time


I see a discrepancy in the benchmarks I run between "code check & profile" and the GetPerformanceCounter( ).

Here is the code I run (in 1m timeframe, the database base interval):

SetChartOptions( 0, chartShowArrows | chartShowDates );
_N( Title = StrFormat( "{{NAME}} - {{INTERVAL}} {{DATE}} Open %g, Hi %g, Lo %g, Close %g (%.1f%%) {{VALUES}}", O, H, L, C, SelectedValue( ROC( C, 1 ) ) ) );
Plot( C, "Close", ParamColor( "Color", colorDefault ), styleNoTitle | ParamStyle( "Style" ) | GetPriceStyle() );

B1 = SelectedValue( BarIndex() );
B2 = BarCount -1;
Lv = SelectedValue( L );
Hv = SelectedValue( H );
Pv = Lv - (Hv-Lv);
loopnum = 497;

GetPerformanceCounter( True ); // reset counter to zero
for ( i = 1;i <= loopnum;i++ )
    tmpLine = LineArray( B1, Lv, B2, Lv, 1 );
    Plot( tmpLine, "Low", colorBlue, styleLine | styleNoRescale );
t1 = GetPerformanceCounter();

GfxSetCoordsMode( 1 ); // bar/price mode (instead of pixel)
GfxSelectPen( colorBlue );

GetPerformanceCounter( True );  // reset counter to zero
for ( i = 1;i <= loopnum;i++ )
    GfxMoveTo( B1, Hv  );
    GfxLineTo( B2, Hv );
t2 = GetPerformanceCounter();

GetPerformanceCounter( True );  // reset counter to zero
for ( i = 1;i <= loopnum;i++ )
    PlotGrid( Pv, colorBlue, 10, 1, true );
t3 = GetPerformanceCounter();

printf( "LineArray time (ms): " + numtostr( t1 ) + "\n" );
printf( "GfxLineTo time (ms):"  + numtostr( t2 ) + "\n" );
printf( "PlotGrid time (ms):"  + numtostr( t3 ) + "\n" );
printf( "diff1           (ms): " + NumToStr( t1 - t2, 1.4 ) + "\n" );
printf( "diff2           (ms): " + NumToStr( t1 - t3, 1.4 ) + "\n" );

This is the output:

LineArray time (ms):    2.646
GfxLineTo time (ms):   0.213
PlotGrid time (ms):   0.371
diff1           (ms): 2.4336
diff2           (ms): 2.2752

So total execution time should be a little above 3ms.

This is what Code Check & Profile reports:

This is more that 48ms, about 15 times more.

More specifically, the 1st method reports that the Gfx method is a lot faster than the PlotGrid. However the second method reports that GfxMoveTo+GfxLineTo is a little slower than PlotGrid.

Am I doing something wrong ?


Did you notice the text in Code Check and Profile saying "QuickAFL turned OFF - all bars used" - that is why you are getting difference. You are comparing QuickAFL ON (chart) with QuickAFL OFF (code check and profile). Number of bars is different, so execution time is different too.
Besides AmiBroker uses various internal optimizations NOT to do work that does not have effect. Depending on context same function may do more or less work. Gfx* functions used in non-chart context do nothing. Third thing is that the timings you get are for AFL execution, not for rendering. Rendering is done after execution.


So is there a way to benchmark the Gfx and PlotGrid functions at all?

The Code Check & Profile is NON-chart. The GetPerformanceCounter is during execution and BEFORE rendering.


Turn on "display chart timing" in Tools->Preferences->Miscellaneous this will give you rendering time.


Thank you very much.

In case anybody is interested, here are the corrected benchmarks:


Yes Gfx* functions are low overhead (i.e. fast) because they are very close to Windows GDI calls.
For single line GfxLineTo will always be fastest.
Plot() function is designed to plot charts, that consists of hundreds/thousands/millions of line segments. For this task (i.e. plotting charts) Plot() is way faster than when you used hundreds/thousands of GfxLineTo calls to draw a chart.

As for rendering time, you need to know that GDI rendering times depend on line style and width. Solid 1 pixel lines are fastest. Dotted lines are way slower in GDI. Since PlotGrid() plots dotted line it is obviously slower than solid GfxLineTo, but if you compared apples to apples (solid line vs solid line of the same length and thickness) rendering time will be the same.


In my code I have

 PlotGrid( Pv, colorBlue, 10, 1, true );

The 3rd parameter is 10, which means "solid line". Right?


Please see this screenshot.

The script is very slow. Indeed the figure ON THE CHART reports 2592.4ms AFL execution time.

However the Code Check & profile reports only 87.283 ms (0.087283 sec).


I don't know if it helps, but the script is initially fast. However as I move back and forth, the script becomes much slower. So I am trying to figure out which procedures spend more resources.


In your case, during Code Check & Profile only 11 491 data bars were used, but your chart uses all available bars. That is a huge difference.


Are you additionally using SetBarsRequired(sbrAll, sbrAll); in your code (which is not present in the code that you pasted here)?


Hello Milosz

Yes, I am using

SetBarsRequired( sbrAll, sbrAll );

However I thought my database contains only this, ie 11491 bars (1m base inerval). I went into Quote Editor. The earliest entry is indeed the first bar on my chart.

I just checked with Tools -> Performance Monitor. It reports 39424 bars.



LineArray is much slower than PlotGrid and GfxMoveTo + GfxLineTo. For this reason I almost never use LineArray. Timings of PlotGrid are almost identical to combined timings of GfxMoveTo and GfxLineTo.




That script is different. The current issue is about CodeCheck & Profile reporting different AFL execution time than the Chart does:


I am using Linearray when I want to construct a piece of array, and not to just plot.


That is because PlotGrid is essentially doing GDI calls to MoveTo/LineTo plus it draws Y axis label.

LineArray serves different purpose. It is provided NOT to draw lines, but to detect crosses of lines against other indicators using combination of LineArray and Cross.


Could you give an example for this?

I am using LineArray to create the linear array segment between two selected points. And by repeatedly calling LineArray, I create my own array, something like my own zigzag. Exactly as described in the documentation:
"Note 2: the function accepts only numbers therefore generates single line. To produce multiple lines you have to call it many times with different co-ordinates. "


I think I found what causes the big delay in chart AFL execution time:

When I move the current bar back and forth, the following process shoots up to 50% cpu usage: MSMPENG.exe

It is part of the Windows Defender anti-malware system. I'll try to see what is wrong with it.


Well, that sounds strange :wink:

Some other possible reasons for the discrepancies between Code check & profile and GetPerformanceCounter() besides those mentioned above by Tomasz:

  1. Code check & profile is applied always on base time interval of a symbol. So you will get different readings when using a chart in a different interval than the base time interval. GetPerformanceCounter calculates timings on selected interval.

  2. You might get different results if your code uses Param functions. Editor always uses default parameter values as specified in the code.

  3. SelectedValue would give you always LAST bar value in code check, but in chart it would give you clicked bar value.

You might be also interested in the thread, where some time ago I raised a similar problem, and thanks to extensive @fxshrat help and @Tomasz response I understood what the cause of my initial misunderstanding was. Here is this thread: Code check & profile / GetPerformanceCounter()



Tomasz has already explaind to me points 1, 2 and 3.



I clicked on it but the access is restricted.


I excluded Amibroker from the Windows antivirus system. This seems to have fixed the problem.



That's a pity you didn't mention that earlier and didn't write about it - so that other forum members could learn that too. I wouldn't need to make this short (above) resume ...


Isn't it your account? If yes, you were active there... I remember that @fxshrat has spent many hours helping this user on the proboards forum...