8 replies to this topic

[Pete Brown]

Does the Netduino Plus (or Netduino) include any type of profiling capability? I'm looking for even pretty basic stuff like whether or not I'm CPU bound (MCU bound? <g>) in some operations. Pete

[Chris Walker]

Hi Pete, Not today, although there's an infrastructure there where it could be added. It's on our wish list for a future version of .NET MF for sure (and technically it could be added by the community). Chris

[CW2]

Not today, although there's an infrastructure there where it could be added.

If I understand it correctly, the profiling support is already there ('Instrumented' build configuration), but it is disabled for 'small' platforms.

[Pete Brown]

Not today, although there's an infrastructure there where it could be added. It's on our wish list for a future version of .NET MF for sure (and technically it could be added by the community).

Thanks Chris. Would be a nice to have addition in the future. I'm running into some issues that smell like perf, but I can't be sure without some profiling mechanism.

I use tick counts for now.

Pete

[Chris Walker]

Have you seen the System.Diagnostics.Stopwatch class (in the project showcase forum)? Chris

[Pete Brown]

Have you seen the System.Diagnostics.Stopwatch class (in the project showcase forum)?

Yep, thanks. I modified it slightly to get elapsed ticks back as an option. That's what I'm using.

Pete

[Illishar]

If I understand it correctly, the profiling support is already there ('Instrumented' build configuration), but it is disabled for 'small' platforms.

I asked Microsoft about 'profiling' some time ago. The answer was, that it's only 'prepared' at this point. It is however very much prepared. In the PK code you'll find a lot of macros like 'NATIVE_PROFILE_CLR' etc. And in the 'tools/bin/Test' dir (in the PK) you'll find a 'MFProfiler.exe' program. So it's rather close I imagine.

[JonnyBoats]

Thread priority is supported in the micro-framework, correct? Why not just spin off a lowest priority thread and have it update a counter. Then have a "test" program run the thread for one min and check the counter. The thread will have used virtually 100% of the CPU time, so the value returned by the counter represents 100% of the CPU for 1 min. Now add the thread to the "real" program you want to benchmark. Run it for however long it takes and check the time and count at the end. You can now compute what percentage of the time the CPU was idle. Example: Suppose the "test" program counts up to 200 in one minute. Now you put it into your real program which runs for 4.5 minutes and counts up to 300. In 4.5 min if your program did nothing you would expect the count to be 200 times 4.5 or 900. Since the count was only 300 you can compute that the CPU was idle (and thus able to increment the count) 300/900 or 1/3 of the time. This is exactly how Windows on the desktop computes CPU usage.

[Chris Walker]

Hi Jonny, The multi-threading priority on .NET MF runs a bit different than on the desktop. High-priority threads get the highest % of CPU cycles, but low-priority threads still get a portion of CPU. It's basically round-robin, but with the highest-priority threads getting more CPU time. Chris