Dumb benchmarks

 

I'm not sure I should have created this topic, but it's never too late to delete it😁

 
If you wrap a switch in a method, it looks like the compiler will inline it. If this seems obvious to you even without a benchmark, please reread the topic title😁.
Files:
 
Vladislav Boyko #:
If you wrap a switch in a method, it looks like the compiler will inline it. If this seems obvious to you even without a benchmark, please reread the topic title😁.

Today I thought the compiler might have gotten rid of the switch because PRICE_WEIGHTED was hardcoded. So I added an input parameter. But this did not affect the results. I have attached the updated script file.

[edit] I can't actually say for sure that the method is inlined. But for myself, I came to the conclusion that if I wrap the switch in a method (which also accepts arrays), it will not affect performance.
Files:
 

ExponentialMAOnBuffer() function from <MovingAverages.mqh>:

int ExponentialMAOnBuffer(const int rates_total,const int prev_calculated,const int begin,const int period,const double& price[],double& buffer[])
  {
   //...
   if(prev_calculated==0)  // first calculation or number of bars was changed
     {
      //--- set empty value for first bars
      for(int i=0; i<begin; i++)
         buffer[i]=0.0;
      //--- calculate first visible value
      start_position=period+begin;
      buffer[begin] =price[begin];

      for(int i=begin+1; i<start_position; i++)
         buffer[i]=price[i]*smooth_factor+buffer[i-1]*(1.0-smooth_factor);
     }
   else
      start_position=prev_calculated-1;
//--- main loop
   for(int i=start_position; i<rates_total; i++)
      buffer[i]=price[i]*smooth_factor+buffer[i-1]*(1.0-smooth_factor);
   //...
  }

I was wondering if "(1.0-smooth_factor)" is recalculated with each loop iteration or if the compiler optimizes it away.

I made a copy of this function in which this expression is explicitly calculated once - CBenchNew::newEmaOnBuffer(). Then I tried to compare the performance. I have attached a script which is the result of my attempts.

It appears that the new function has approximately the same performance as the original. Either due to compiler optimizations or the time spent on calculating that expression can be neglected.

Files: