[USDCHF]: 22784 of 22833 (99.8 %) ticks were processed (0.14 ms delay in average), 49 (0.2 %) ticks were skipped (103.4 ms delay in average)
[EURUSD]: 22944 of 22974 (99.9 %) ticks were processed (0.16 ms delay in average), 30 (0.1 %) ticks were skipped (115.6 ms delay in average)
[USDCAD]: 15331 of 15347 (99.9 %) ticks were processed (0.13 ms delay in average), 16 (0.1 %) ticks were skipped (104.6 ms delay in average)
[EURCHF]: 22516 of 22571 (99.8 %) ticks were processed (0.13 ms delay in average), 55 (0.2 %) ticks were skipped (127.8 ms delay in average)
[EURAUD]: 66842 of 66924 (99.9 %) ticks were processed (0.13 ms delay in average), 82 (0.1 %) ticks were skipped (117.8 ms delay in average)
[GBPUSD]: 41393 of 41393 (100.0 %) ticks were processed (0.00 ms delay in average)
Total trade requests time: 4.280 sec
Структура для получения текущих цен - Структуры данных - Константы, перечисления и структуры - Справочник MQL5 - Справочник по языку алгоритмического/автоматического трейдинга для MetaTrader 5
然后，指标1和指标2必须以某种方式同步，以便两个数字可以写在同一个公共行上。
这是一个非常复杂的解决方案。
为什么它们需要同步呢？user32.dll将为它们做这个。
最主要的是对它们进行正确的编号，这样每个数字都有一个唯一的号码，这个号码将成为数据数组的索引。
，作为最后的手段，这可以手动完成。或者你可以自动进行。顺便说一下，我最近在KB（指标案例） 上发表了类似的东西。
有什么理由不喜欢这些资源呢？我认为在一个终端的范围内是最佳的。我建议的变体，使用user32.dll（我在大约10年前实现了这个变体，当时我还很年轻，涉足套利），访问时间和数据解析大约是50微秒（我认为可以加快1.5-2倍）。有了资源之后，速度会不会变慢？
为什么他们需要同步呢？user32.dll将为他们做这个。
试着写一下吧。也许你并不完全理解这项任务。
你为什么不喜欢资源？我认为在单个终端的范围内是最佳的。我建议的变体，使用user32.dll（我大约在10年前实现了这个变体，当时我还很年轻，涉足套利），访问时间和数据解析大约需要50微秒（我认为可以加快1.5-2倍）。有了资源之后，速度会不会变慢？
在理想条件下，在家用机器上读取需要100微秒的时间。一个专家顾问在一个刻度上可以引起一百次的阅读。它很慢。
在理想情况下，GlobalVariableGet 将在10微秒内执行。但这不是一个指标，因为在对我来说新的战斗条件下，这是一个可怕的刹车。
这是HistoryTicks--为EA捕捉所有ticks。因此，EventChartCustom不适合，它有自己的队列。缓冲区的情况也是如此。
我已经在EventChartCustom上工作了。99.8%的蜱虫是在0.15毫秒内收到的。
关于交易、自动交易系统和策略测试的论坛
EventChartCustom => 指标太慢了
Andrey Khatimlianskii, 2019.12.12 09:27
以下是用5个符号工作9小时的统计数字。
专家顾问是在GBPUSD上，所以原生的OnTick对它有效。
没有出现 "指标太慢 "的错误。
相比之下，在 MQ的VPS上，错过的时间百分比和平均延迟要高得多（我稍后会公布统计数据）。
而且有很多 "指标太慢 "的错误。
我不明白队列溢出的性质，因为专家顾问会立即处理累积的事件（它只是返回）。
还有人加工吗？
我已经在EventChartCustom 上工作了。99.8%的蜱虫是在0.15毫秒内收到的。
我通过这样的方式从指标中发送ticks：sparam包含MqlTick，lparam - tick号码。
OnChartEvent 中的Expert Advisor捕捉到了这些ticks。它需要了解当前的刻度是否是最实际的刻度？即，是否有一个蜱虫队列，或者它是空的？
为此，它读取指标所发送的最新刻度线的数字（任务是读取这个数字）。如果刻度线有相同的数字--队列是空的，就有可能开始处理刻度线。
而在OnTick的操作过程中，在OrderSend之后，有必要检查指标是否已经发送了更多的ticks。为此，我们需要再次从指标中读取数字。在一个OnTick期间，可能会有超过100个这样的检查。这就是为什么我们需要快速阅读。
在1个终端内，最快的winapi将是内存分配（在一个进程内的全局）和互锁的功能，如https://docs.microsoft.com/ru-ru/windows/win32/api/winnt/nf-winnt-interlockedexchange。
这些都是非阻塞性的，原子性的，基本上是用几条asm指令执行。
在1个终端内，最快的winapi将是内存分配（在一个进程内的全局）和互锁的功能，如https://docs.microsoft.com/ru-ru/windows/win32/api/winnt/nf-winnt-interlockedexchange。
这些都是非阻塞性的，原子性的，基本上是用几条asm指令执行。
不是没有例子。
为了做到这一点，它读取指标最近发送的tick的数字（任务是读取这个数字）。如果收到的tick有相同的数字--队列是空的，你可以开始用一包tick工作。
而在OnTick的操作中，在OrderSend之后，有必要检查指标是否已经发送了更多的ticks。为此，我们再次需要从指标中读取数字。在一个OnTick期间，可能会有超过100个这样的检查。因此，我们需要快速阅读。
初始化。
1.在第一个线程（很可能是写线程）中，以任何方式为所需大小的变量分配内存。
2.在所需的线程（读取线程）中，发送该内存的地址。
基本工作。
3.写入线程启动InterlockedExchange或InterlockedExchange64，这取决于向其写入的变量大小。
4.读取线程拉动例如InterlockedCompareExchange来读取。
完成。
5.释放分配的内存，最好是在分配内存的同一个线程中。
如果有必要，可以重复创建几个计数器。缺点是，你将需要WinAPI连接。所分配的内存地址的特征应该是对齐的，但默认情况下，它通常是对齐的。
工作将在1个进程中进行，内存为1个进程的线程所共享。如果需要，还有其他联锁函数，如InterlockedDecrement、InterlockedAdd等。
函数是无阻塞的，不等待任何东西，自动机，它们在几个asm指令中执行。
P.S. 在我的记忆中，无论如何，在汇编中通过mov进行的常规读写操作都是原子性的。而如果编译器不制造混乱（理论上不应该），我们可以尝试在分配的内存中读写变量，而且会是原子性的。
如果适合任务，不太可能在1个过程中更快。对于进程间来说，最快的速度将是类似的，但有共享内存，在这种情况下你不能没有WinAPI。
这个计划似乎并不奏效。请出示一个基本的例子。
为什么不可行？只是我看到的方式。getter setter原则。
通过一个函数获得一个隐藏变量的值。
如果你传递的是MqlTick结构，那就用MqlTick那样的字段设置来定义你的结构，并将你的计数器字段添加到结构中。
并从导出函数中返回这个结构。
该指标的一个基本例子。不要注意脚本中的例子。
在专家顾问中，调用GetTickStruct，获得带有你的计数器的整个结构。
在专家顾问中，你调用GetTickStruct，你会得到整个结构，包括其计数器。
请写一个从指标到EA 的基本数字转移。
从指标到EA 的基本数字转移，请写。
用一个变量替换结构））。