Указывает клиентскому терминалу, что для данного эксперта или индикатора необходимо генерировать события таймера с периодичностью менее одной секунды. нужно получать события таймера чаще, чем один раз в секунду. Если вам достаточно обычного таймера с периодом более 1 секунды, то используйте EventSetTimer(). В тестере стратегий используется...
不，我有虚拟机在CentOS上旋转。但我没有能力继续这种对话。
反正是双重虚拟化。
CentOS -> VirtualBox -> Windows 7
此外，当CPU为8核时，削减到2核，极大地改变了线程调度器的行为和分配资源。
这2个核心将不得不分配给不可避免的1000个线程，即使是截断的Windows 7。因此，终端保证会有增加的延迟。
好吧，你是一个不控制相关性和合理性的赛车压力测试的大师。
当然，微秒计量需要资源，能够测量比一毫秒小1000倍的间隔。
如果你偶尔 需要超级精确地测量间隔，那么就使用微秒。而这将花费你0微秒的时间。
当微秒是拖累你的东西时，你如何使用微秒？这里一共有20个电话。四分之一毫秒的时间里，各种实际任务的调用数量 如此荒谬。
在一个被扼杀的VPS上，通过timeBeginPeriod来超频系统定时器是充满危险的。你只会增加CPU的开销。
否则，你早就在操作系统中使GetTickCount/GetTickCount64准确无误，并为免费的准确性感到高兴了。但是没有，你必须为这个计时器的准确性付费。
GetTickCount在速度上绝不逊色。改为在慢速VPS上使用，而不是GetMicrosecondsCount。在真实的交易中，负荷从50%下降到2%。
当它是慢下来的时候，你如何使用微秒？这里只有20个电话。四分之一毫秒的时间里，各种实际任务的调用数量 如此荒谬。
而我有这20个电话。
GetTickCount在速度上绝不逊色。改为在慢速VPS上使用，而不是GetMicrosecondsCount。在真实的交易中，负载已从50%下降到2%。
我不相信替换GetMicrosecondsCount -> GetTickCount会在真正的程序中得到。在理论上和实践上都没有证据。
在对这两个函数的压力测试中，你可以很容易得出这样的结果。你自己得出结论，48%的CPU负载是由微秒来衡量的吗？这不是一个压力测试吗？当然是这样。
关于多媒体定时器加速--这又是压力测试，不看整体性能的下降。任务洗牌器的超频增加了操作系统的系统开销。
仍然是双重虚拟化。
CentOS -> VirtualBox -> Windows 7
此外，当CPU为8核时，削减到2核，极大地改变了线程调度器的行为和分配资源。
这2个核心将不得不分配给不可避免的1000个线程，即使是截断的Windows 7。因此，终端保证会有增加的延迟。
我也得出了这个结论，谢谢你的确认。VirtualBox是邪恶的。
而且特别要小心vps，在这样的部署上，有很多vps。
，只有硬件上的纯操作系统，而且最好是Linux。
虽然通过wine，同样的虚拟化，但终端的GUI却没有一点滞后。
而GetMicrosecondsCount的滚动没有任何滞后。
而我有这20个电话。
好吧，这对我来说也是零微秒!只在我的家用机器上。
我不相信将GetMicrosecondsCount->GetTickCount替换成一个真正的程序就可以了。在理论上和实践上都没有证据。
在压力测试中，你可能很容易用这两个函数画出这样的错误。你自己得出结论，48%的CPU负载是由微秒来衡量的吗？这不是一个压力测试吗？当然是这样。
这条线索促使我写了一个Benchmark库，这样我就可以简单地在源代码中插入运行时检查。而且它相当广泛地利用了这一点，揭示并消除了很多坏东西。
因此，以这种方式编写的专家顾问（更准确地说，是20个专家顾问并行）使一台家用电脑的负载达到1.5%。但VPS是50+%。当我开始挖掘的时候，我看到微秒计时器的速度在减慢。相应地，如果在家用机上没有产生警报，VPS 就会失败。
但即使这样也是不够的。由于这个分支，一个快照机制被开发出来，其基础是这样的。
这是所有快照的基础：如果距离上一次快照的时间少于指定的时间，我们什么都不做。正是这种方法使你能够大大节省资源。
当然，刷新时间很短--默认是一毫秒。这就是使用微秒计时器的原因。
这个计时器的缓慢导致了快照机制的崩溃，因为它花了一个完整的快照，其频率是完整机器上的两倍。
这就是微秒定时器刹车的派头。但当我切换到毫秒计时器（而不是16ms）时，一切都开始飞起来了，即使是在慢速的VPS上。
关于多媒体定时器加速--这又是压力测试，不考虑整体性能的下降。超频的任务管理器增加了操作系统的系统开销。
如果在实践中收益巨大，谁还在乎这些理论呢？也许，它确实影响了一些游戏。但在VPS上，它是一根救命稻草。
所以对我来说也是零微秒!只在我的家用机器上。
这个话题促使我写了一个Benchmark库，这样我就可以直接在源码中插入运行时检查。而且它相当广泛地利用了这一点，揭示并消除了很多坏东西。
因此，用这样的修改编写的专家顾问（更确切地说，是20个专家顾问并行）对家庭电脑的影响是1.5%。但VPS是50+%。当我开始挖掘的时候，我看到微秒计时器的速度在减慢。相应地，如果在家用机上没有产生警报，VPS 就会失败。
但即使这样也是不够的。由于这个分支，一个快照机制被开发出来，其基础是这样的。
这是所有快照的基础：如果距离上一次快照的时间少于指定的时间，我们什么都不做。正是这种方法使你能够大大节省资源。
当然，刷新时间很短--默认是一毫秒。这就是使用微秒计时器的原因。
因此，由于这个定时器的速度很慢，快照机制崩溃了，因为正式的快照比正式的机器上的快照要频繁得多。
这就是微秒计时器刹车的那种派头。但当我切换到毫秒计时器（而不是16ms）时，一切都开始飞起来了，即使在慢速的VPS上。
我不关心这些理论，只要实际效益巨大就好。也许它确实影响了一些游戏。但在VPS上，它是一根救命稻草。
看看这句话说得多漂亮。
改为在慢速VPS上使用，而不是GetMicrosecondsCount。在实际交易中，负载从50%下降到2%。
结论是不可避免的，"都是因为微秒计量的刹车，这就是加速的原因"。
突然发现 "我自己由于一个逻辑错误而使计算结果大了一个数量级"。而GetMicrosecondsCount只是这个错误的一个触发器。
对GetTickCount的重做是对这个错误的修复/破解，修复的代码没有显示。因为它不只是替换GetMicrosecondsCount -> GetTickCount？
为什么不能马上说呢？
这种逻辑似乎被会计的明显引导（从微秒到毫秒的跳跃）和快照创建的多重减少所加速。
这是在一台用1.5%的CPU研磨20个EA的机器上进行的。其中LatencyMon显示，一切正常。
MT5架构中的某些东西让所有正在运行的EA同时出现这些滞后。而我没有。
对GetTickCount的转换是对这个bug的修复/破解，而修复代码没有显示。因为它不只是替换GetMicrosecondsCount->GetTickCount？
为什么不能马上说呢？
不过，与我的讨论是以显示的东西的存在为特征的。没有什么是隐藏的，相反，它是公开发表的。
当然有一个压力测试。没有其他方法可以直观地展示它。
想象一下，一个马特罗什卡娃娃形式的函数。对外面的马特罗什卡进行测量。同时，对内部嵌套的娃娃也进行了测量。结果，由于微秒制动，外部嵌套的娃娃在执行时间上显示出疯狂的数字，这就造成了一型警报的出现。显然，调用一次GetMicrosecondsCount的10微秒是非常昂贵的。所以我匆匆忙忙地发出了警报。
自由粗糙的毫秒计时器开始发出0µs、1000µs或2000µs的信号。这大大减少了警报的数量，并减少了定时器函数调用时的制动。
而用快照，就很好。与家用机相比（那里的微秒），装载量不是很大。但如果你把它与VPS上的东西相比，它就像天堂和大地。
ZZY 我们现在讨论的是在MQL中拥有毫秒级计时器的可行性，不幸的是，这并不存在。没有它，你就不能在VPS上快照。
我仍然在考虑使用SymbolInfoTick快照来避免这种东西。
这是在一台以1.5%的CPU研磨20个EA的机器上进行的。其中LatencyMon显示，一切正常。
MT5架构中的某些东西让所有正在运行的EA同时出现这些滞后。而我没有。
这是我的代码和稳定的响应时间：在20个并行的图表上没有数百或数千微秒的时间
你有多少个核心，什么样的处理器？ i7-2600？
又是一个隐藏的压力测试，有数百万个并行的请求？
要更加透明。仅仅因为你贴出了几个简单的_B电话，并不能证明你的其他主张。你一提出离谱的要求，就突然忘记了代码和条件的实际描述。
你不需要在头脑中想象什么--告诉并展示你实际调用和测试的东西。不是 "运行了一个未知的压力测试并等待警报来显示世界 "的撕掉的结果，而正是测试的完整代码。
还有一些关于测量库本身的问题。有很多不必要的东西，包括开销。
。
我们现在谈论的是在MQL中拥有一个毫秒级计时器的用处，不幸的是，这个计时器并不存在。没有它，你就不能在万国邮联上快照。
早就有一个毫秒级的计时器： EventSetMillisecondTimer()