1 回答
TA贡献1798条经验 获得超3个赞
请忽略声称 .NET刻度线分为两部分的评论DateTime
。这个评论是不正确的。该属性返回单位为“百万分之一秒”DateTime.Ticks
的刻度计数,并测量从“公历 0001 年 1 月 1 日 0:00:00 UTC”开始的刻度数。它是一个直接整数值,所有位根据其在该值中的重要性对总数做出同等贡献。
现在,就结果的差异而言……
C++ 表达式为您提供当天的current_date_microseconds.time_of_day().total_milliseconds()
总毫秒数。即,这是自午夜以来的总毫秒数(根据该值,您似乎在当地时间下午 3 点左右执行了代码)。
另一方面,.NET 表达式使用的DateTime.Now
是测量自纪元开始(即自 0001 年 1 月 1 日以来)的毫秒数。
这两个值根本没有可比性。它们代表了两个完全不同的时期。
理论上,您可以通过在 .NET 端使用DateTime.Now.TimeOfDay.TotalMilliseconds
. 这将使您更接近您期望的值。
然而…
我不清楚是否能保证您使用的 C++ POSIX API 将使用与 .NET API 完全相同的时钟参考。此外,即使是这样,API 本身也会产生一些开销,并且线程调度扰动可能会在计算中引入错误。
在我看来,更好的方法是在 .NET 端使用类System.Diagnostics.Stopwatch
来测量调用 C++ DLL 所花费的整个时间,然后在 C++ DLL 中,使用 POSIX API 来测量C++ 代码执行并将其传回 C# 端所需的时间。
然后,C# 端只需从自己的时间中减去 C++ 时间,即可大致确定调用的总开销是多少。(当然,确保每个值使用完全相同的单位……例如毫秒。)
即便如此,重要的是要记住:
如果您在同一调用中返回 C++ 时间值,则其本身可能会影响调用的总开销。
一些明显的开销可能是线程调度的影响。即,如果您的线程在调用期间被抢占,那么您的测量的一部分将是线程被抢占的时间。
至少在 .NET 方面,可能在 C++ 方面,计时的精度仍然存在限制。该类
Stopwatch
肯定比 更精确和更可取DateTime
,但是如果开销足够小,您可能不会获得有用的结果(但是当然,如果它那么小,那么可能足以发现它太小而无法获得有用的结果: ))。
- 1 回答
- 0 关注
- 87 浏览
添加回答
举报