问题标签 [gettickcount]

此代码仅在 Windows 上运行，但我想使用 C++ 标准库，以便它可以在其他地方运行。

我搜索std::chrono了，但我找不到像GetTickCount().

你知道我应该使用std::chrono什么吗？

我正在尝试对脚本进行故障排除，并且我 99% 肯定它是我正在运行的 CFHTTP 函数，因为当我删除它时，页面似乎要快得多，但它不一致。也就是说，即使页面运行时间很长，我围绕 cfhttp 请求输出的滴答计数也很短。我不确定 CFHTTP 是否在 tickcount 范围内运行，因为它发出了远程处理请求。当我隔离这两件事时，滴答计数不匹配。

有谁知道一种方法来获得执行 CFHTTP 函数所需的时间而不使用 tickcount 以便我可以正确测试它？我正在使用 CF9（由于某些不受我控制的原因而不是 901），所以我们也没有 http 日志记录。

谢谢一堆。约翰

我试图在一个更大的 c++ 程序中嵌入一个 python 模块（相关细节：VS2005，WinXP Python 2.7）。当我创建包含“python.h”的类的新实例并尝试运行我的程序时，我收到错误消息“无法在动态链接库 KERNEL32.ll 中找到过程入口点 GetTickCount64”。我在网上看到会发生这种情况，因为 XP 中不存在 GetTickCount64，所以我确保将正确的 Windows 标题添加到我的所有文件中。但是，即使我注释掉除了 Python.h 的包含之外的违规类中的所有内容，我仍然会收到错误消息。所以要回答一个实际的问题。我想知道 Python 本身是否可以调用或包含 GetTickCount64，如果可以，如何阻止它这样做。

谢谢你的帮助！

我对计时器有一个奇怪的问题。据我所知，计时器的间隔属性表示将触发 timer_Tick 事件的循环之间的延迟。

在使用 Visual Basic 编程之前，我遇到了精确签名（15 和 16 毫秒延迟）的问题。我创建的任何计时器都会以 15 或 16 毫秒的延迟触发它们的滴答事件。例如，如果我将计时器的间隔设置为 1（这意味着它的滴答事件应该在 1 秒内触发 1000 次），则该事件会在 1 秒内触发 62 到 66 次（即 1000/16 到 1000/15 ）。

我从 5 年前开始开发 VB 应用程序并且一直遇到这个问题（这也意味着我在使用 AMD 和 Intel 处理器的几个不同系统上遇到了这个问题），现在我又在 C# 中遇到了这个问题。

我设法通过基于 TickCount 方法（VB 中的 GetTickCount API 和 C# 中的 Environment.TickCount）计算每次触发滴答事件之间的时间差来解决此问题。

*TickCount 是自系统启动以来经过的毫秒数。

为了更好地理解这个问题，我创建了一个 Windows 应用程序，它计算自执行以来的秒数（如计时器）。每次触发 Tick 事件时，它都依赖于 TickCount 和普通加法。它还通过从 TickCount 的当前值中减去 TickCount 的最后一个值来计算计时器的延迟（如果计时器确实在 1 秒内被触发了 1000 次，那么每次 TickCounts 的差值将是 1，因此意味着没有延迟，但如果差值大于 1，则每次触发计时器的滴答事件之间会有一些延迟）。

这是代码：

我还在这里上传了整个解决方案：http ://ramt.in/test/TimerDelay.zip

这是应用程序的屏幕截图（延迟 15 毫秒，应用程序计算 1 秒，而实际上已经过去了 17 秒！）：

该解决方案只有 50kb，所以请随意下载并运行它，看看您是否得到与我相同的结果。如果相同，那么微软世界的计时器类有问题！

但更重要的是，如果有人知道可能导致此延迟的原因，请与我分享您的知识。

查看以下代码：

tick2-tick1 大多数时候都小于 100。我的期望是它应该总是 100+。我的期望错了吗？

我想转换日期格式“Www Mmm dd hh:mm:ss yyyy”，并将“dd hh:mm:ss”复制到 C++ 中的字符串。
到目前为止，我一直在寻找它：

我有这个开关，我需要在 c++ 中使用 gettickcount() 每 x 秒执行一次案例。在此先感谢，对不起我的西班牙语：D

我知道GetTickCount()并且timeGetTime()有不同的分辨率，并且timeGetTime()可以通过调用来设置计时器分辨率timeBeginPeriod()。

我的理解是，增加计时器的分辨率使用timeBeginPeriod()减少了系统在连续递增到后面的计数器之间的睡眠时间timeGetTime()。

假设时间分辨率GetTickCount()为 16ms（其值每 16ms 增加 16），我将分辨率设置timeGetTime()为 1ms（其值每 1ms 增加 1）。我的问题是关于刻度计数器更新的时间点。我编写了一个小型测试程序，以查看在滴答计数器增加时计时器落后于滴答计数器的滞后情况。滞后我的意思是不同GetTickCount()-timeGetTime()就在GetTickCount()更新时。例如，滞后 0 意味着当函数timeGetTime()返回 32 时滴答计数器从 16 更新到 32，滞后 4 意味着当timeGetTime()返回 28 时滴答计数器从 16 增加到 32。这是代码：

令我惊讶的是，虽然两个函数之间的延迟在我的程序一次运行期间是恒定的，但在程序的重复执行之间差异很大。我希望这两个函数背后的计数器总是在后台运行，所以我认为执行之间的延迟应该是恒定的。

起初我认为增加timeGetTime()-timer 的分辨率可能会通过在两者之间引入一些随机延迟来导致这种情况，但是当我在执行之间将分辨率保持在 1 毫秒时，执行之间的延迟仍然会有所不同。

有谁知道是什么机制导致这种行为？

在阅读此问题及其答复时，Environment.TickCount 还不够， 我感到困惑。

他们说它Environment.TickCount可以使用 48-49 天（OP）（@Cody Gray 说 25 天），但它是一个int值，因此最多可以存储 2,147,483,647。

现在，1 毫秒包含 10,000 个滴答声，这意味着它最多可以容纳 214,748.3+ 毫秒，也就是 214+ 秒，不到 4 分钟。

我错过了什么吗？

顺便说一句，现在有Environment.TickCount64一个提供 64 位值的。

我正在用 vba 编写一些 winsocket 应用程序，并且可能会超时。

我已经尝试过 API-Timer Settimer 和 Killtimer，但是你必须小心地启动和停止与普通 vba 程序并行的计时器。

vba 中包含的 timer() 函数不是很精确，所以我决定在 32 位办公系统上使用 GetTickCount 对定时器进行编程。

但问题是 24.9 天后计数器重新启动。在较新的系统上，您现在可以使用 longptr 和 GetTickCount64 i，但它也应该在旧的 Windows 32 位系统上运行。

所以我编写了类似环形计数器的代码约 1 秒，但我不确定

• 如果您可以更好地编码或
• 即使它在 24.9 天后有效

那么您能否对我的测试程序（用excel vba编码）做出一些回应：