首頁猿問 C++ 和 C# 中的等效系統(tǒng)時鐘毫秒？

C++ 和 C# 中的等效系統(tǒng)時鐘毫秒？

PHP

哆啦的時光機 2024-01-20 15:58:48

我正在使用 .dll 將數(shù)據(jù)從 c++ .dll 傳遞到 C# 應(yīng)用程序DllImport。我想做的是計算數(shù)據(jù)傳輸時間。所以我想在dll函數(shù)中獲取以毫秒為單位的系統(tǒng)時間，然后在C#端再次執(zhí)行相同的操作，并獲取兩者之間的差值來計算所花費的時間。在 C++ 方面，我發(fā)送的信息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作為名為的變量發(fā)送到 C# timestamp，然后運行：long milliseconds = DateTime.Now.Ticks / TimeSpan.TicksPerMillisecond;long elapsed = milliseconds - timestamp;當(dāng)我打印這些值時，它們看起來像這樣：63705280140098 //c#54540098 //c++63705225600000 // elapsed為什么 C++ 值和 C# 值如此不同？如何以這種方式從系統(tǒng)時鐘獲得等效值？

查看完整描述

1 回答

呼如林

TA貢獻1798條經(jīng)驗獲得超3個贊

請忽略聲稱 .NET刻度線分為兩部分的評論DateTime。這個評論是不正確的。該屬性返回單位為“百萬分之一秒”DateTime.Ticks的刻度計數(shù)，并測量從“公歷 0001 年 1 月 1 日 0:00:00 UTC”開始的刻度數(shù)。它是一個直接整數(shù)值，所有位根據(jù)其在該值中的重要性對總數(shù)做出同等貢獻。

現(xiàn)在，就結(jié)果的差異而言……

C++ 表達式為您提供當(dāng)天的current_date_microseconds.time_of_day().total_milliseconds()總毫秒數(shù)。即，這是自午夜以來的總毫秒數(shù)（根據(jù)該值，您似乎在當(dāng)?shù)貢r間下午 3 點左右執(zhí)行了代碼）。

另一方面，.NET 表達式使用的DateTime.Now是測量自紀(jì)元開始（即自 0001 年 1 月 1 日以來）的毫秒數(shù)。

這兩個值根本沒有可比性。它們代表了兩個完全不同的時期。

理論上，您可以通過在 .NET 端使用DateTime.Now.TimeOfDay.TotalMilliseconds.?這將使您更接近您期望的值。

然而…

我不清楚是否能保證您使用的 C++ POSIX API 將使用與 .NET API 完全相同的時鐘參考。此外，即使是這樣，API 本身也會產(chǎn)生一些開銷，并且線程調(diào)度擾動可能會在計算中引入錯誤。

在我看來，更好的方法是在 .NET 端使用類System.Diagnostics.Stopwatch來測量調(diào)用 C++ DLL 所花費的整個時間，然后在 C++ DLL 中，使用 POSIX API 來測量C++ 代碼執(zhí)行并將其傳回 C# 端所需的時間。

然后，C# 端只需從自己的時間中減去 C++ 時間，即可大致確定調(diào)用的總開銷是多少。（當(dāng)然，確保每個值使用完全相同的單位……例如毫秒。）

即便如此，重要的是要記?。?/p>

如果您在同一調(diào)用中返回 C++ 時間值，則其本身可能會影響調(diào)用的總開銷。
一些明顯的開銷可能是線程調(diào)度的影響。即，如果您的線程在調(diào)用期間被搶占，那么您的測量的一部分將是線程被搶占的時間。
至少在 .NET 方面，可能在 C++ 方面，計時的精度仍然存在限制。該類Stopwatch肯定比更精確和更可取DateTime，但是如果開銷足夠小，您可能不會獲得有用的結(jié)果（但是當(dāng)然，如果它那么小，那么可能足以發(fā)現(xiàn)它太小而無法獲得有用的結(jié)果：））。