解决通信计时问题（C++ windows 应用程序）
我有一个与嵌入式设备通信的“遗留”（为我们解决这个问题）应用程序 - 它由外部 OEM 应用程序驱动，该应用程序使用此“应用程序”重新刷新汽车的电子控制单元（ECU） - >通过USB端口与汽车ECU通信->一些通过设备->汽车ECU。
似乎存在一些计时问题（呼叫/响应通常不得超过 100 毫秒），我想知道您建议如何测量所有这些。我认为针对此类问题的记录器当然有帮助，但据我了解/看到，还涉及大量线程和可能的同步。线程当然可能会带来一些问题。有没有一种方法可以让我对与线程/同步相关的时间有一个“整体”视图？例如，如果线程存在一些同步问题，是否有一种方法可以让探查器（采样数据）告诉我等待/同步所涉及的时间？我使用 Visual Studio 2008，但我认为我也可以使用 VS 2010，如果这会有更多帮助的话。
您是否推荐 Visual Studio Profiler（需要团队版？）或者还有其他东西（也可能免费）？ 谢谢
-吉塔
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这个问题已经有一段时间了。这个问题的解决方案是：“完成一个内存记录器（仅在“分析”/程序结束时刷新信息）。”
回想起来这已经足够好了，但现在 Windows 上注重性能的方式是使用 Windows 事件跟踪 (ETW)，因为这将日志记录提供程序与事件跟踪信息的使用者分离，甚至导致日志记录崩溃应用程序不会影响日志记录（直到实际崩溃产生的点）。它还具有其他性能优势，据说它能够处理生产者应用程序生成的数千个事件，而不会出现明显的性能下降。
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.