猿问

C++ 和 C# 中的等效系统时钟毫秒?

我正在使用 .dll 将数据从 c++ .dll 传递到 C# 应用程序DllImport。


我想做的是计算数据传输时间。所以我想在dll函数中获取以毫秒为单位的系统时间,然后在C#端再次执行相同的操作,并获取两者之间的差值来计算所花费的时间。


在 C++ 方面,我发送的信息long如下:


boost::posix_time::ptime current_date_microseconds = boost::posix_time::microsec_clock::local_time();

long millisecondStamp2 = current_date_microseconds.time_of_day().total_milliseconds();

我将其long作为名为 的变量发送到 C# timestamp,然后运行:


long milliseconds = DateTime.Now.Ticks / TimeSpan.TicksPerMillisecond;

long elapsed = milliseconds - timestamp;

当我打印这些值时,它们看起来像这样:


63705280140098 //c#

54540098       //c++

63705225600000 // elapsed

为什么 C++ 值和 C# 值如此不同?如何以这种方式从系统时钟获得等效值?


哆啦的时光机
浏览 105回答 1
1回答

呼如林

请忽略声称 .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,但是如果开销足够小,您可能不会获得有用的结果(但是当然,如果它那么小,那么可能足以发现它太小而无法获得有用的结果: ))。
随时随地看视频慕课网APP
我要回答