我正在使用 .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# 值如此不同？如何以這種方式從系統時鐘獲得等效值？
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++ 時間，即可大致確定調用的總開銷是多少。（當然，確保每個值使用完全相同的單位……例如毫秒。）
即便如此，重要的是要記?。?/p>
如果您在同一調用中返回 C++ 時間值，則其本身可能會影響調用的總開銷。
一些明顯的開銷可能是線程調度的影響。即，如果您的線程在調用期間被搶占，那么您的測量的一部分將是線程被搶占的時間。
至少在 .NET 方面，可能在 C++ 方面，計時的精度仍然存在限制。該類
Stopwatch肯定比 更精確和更可取DateTime，但是如果開銷足夠小，您可能不會獲得有用的結果（但是當然，如果它那么小，那么可能足以發現它太小而無法獲得有用的結果： ））。
- 1 回答
- 0 關注
- 163 瀏覽
添加回答
舉報
0/150
提交
取消