Cobra III slow to count to 5000?

NETMF & Gadgeteer
1

Hi,

I was debugging some code running on a Cobra III where my CAN transmit speeds seemed hampered. I pared back and eventually ended up looking at speeds of for loops. I wrote the below standalone code.

using System;
using Microsoft.SPOT;

namespace MFConsoleApplication4
{
    public class Program
    {
        public static void Main()
        {
            long Millis;
            while (true)
            {
                Millis = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;

                for (int i = 0; i < 5000; i++)
                {

                }
                Millis = (Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks - Millis) / 10000;
                Debug.Print("Time(ms)=" + Millis.ToString());

            }
        }
        
    }
}

This consistently showed 100ms to do the loop to 5000. I ticked “Optimise Code” in the project properties and that dropped to 64ms to count to 5000! Am I doing something fundamental here that I have not stumbled across before?

It is still 10,000 ticks to a millisecond…?

I checked on the VS emulator and got 15/16ms, but I don’t know quite how they are expected to compare.

Any pointers much appreciated!

Thanks in advance

Nick

2

It should still be 10,000 ticks per millisecond. To be sure, don’t store the ticks property, just store the TimeSpan itself. Then get the difference of the two and verify.

In general, having the debugger attached will slow down your program to varying degrees.

“Optimize Code” should be checked in the Release configuration. It will only cause some minor IL changes in the final output, it doesn’t do anything regarding optimization on the NETMF side. The resulting “optimized” IL may execute quicker.

All that said, 100ms/64ms for debug/release on G120 (which the FEZ Cobra III uses) for a loop to 5,000 isn’t unexpected given NETMF’s interpreted nature. For tasks requiring quicker or real time performance, you can use Runtime Loadable Procedures to execute native code.

2 Likes
3

Thanks John,

For interest, I will time it when not connected to a debugger and see what it does. It just surprised me when I can get so many other things done in 100ms (such as updating a 320x240 display with all that entails), that a simple loop seemed slow.

Appreciate the reply.

Nick

4

It depends which task you’re doing. For things that call into native code or happen entirely in native code, performance will be really quick. Flushing to the display is one of those quick operations.

5

try a while loop and a do while loop, and see if you get different results.

Also, see if increasing from 5000 to 100000 gives different results. May be a high overhead to initialize for loop, but overall cost per iteration goes down for higher repetitions.

6

The values of your example are true but the example is a little bit misleading to evaluate the speed. Here is an example that copies a byte array with a length of 5000. 100 loops only need 25 ms.

    public static void Main()
    {
        long Millis;
        byte[] source = new byte[5000];
        byte[] drain = new byte[5000];
        while (true)
        {
            Millis = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;

            for (int c = 0; c < 100; c++)
            { 
                Array.Copy(source, drain, 5000);
            }
            Millis = (Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks - Millis) / TimeSpan.TicksPerMillisecond;
            Thread.Sleep(1000);
            Debug.Print("Time(ms)=" + Millis.ToString());
        }
   }