I have a “legacy” (solve this problem for us issue) app that communicates with an embedded device – it’s driven by an external OEM app that reflashes the car’s Electonic Control Units (ECU) using this “app” -> communicates to the car ECU through an USB port -> some pass through device -> car ECU.
It seems that there are some timing issues in there (a call/response has to typically not be > 100 ms) and I was wondering what do you recommend for measuring all this. I was thinking that a logger for this kind of issues is of course of help but as I’ve understood/saw there are involved also lots of threading and possibly synchronization. Threading of course could pose some issues. Is there a way I can have an “overall” view of the timing involved related to threads/synchronization ? For example if there are some sync issues with threads is there a way that a profiler (that samples data) could tell me timing involved in waiting/synchronizing for example ? I use Visual Studio 2008, but I think that I could possibly use also VS 2010 if that would be of more help.
Do you recommend Visual Studio Profiler (requires team edition ?) for this or is there something else (possibly free also) ?
Thanks
-Ghita
There has been quite a while for this question. The solution to this one was: “Done an in memory logger (that only flushes information at the end of the “profiling”/program).”
Looking back that was good enough but now days the performance minded way on Windows would be to use Event Tracing for Windows (ETW) as this decouples the logging provider from the consumer of the event tracing information in such a way that even crashes of the logging application would not affect the logging (up to the point where the actual crash produced). It has also other performance benefits, being said it’s capable of many thousands of events generated by the producer application without visible performance degradation.