Core 1 FILTER_EURUSD.rann_RannForex,M1: 132843 ticks, 60283 bars generated. Environment synchronized in0:00:00.140. Test passed in0:00:00.827 (including ticks preprocessing 0:00:00.109).
Core 1 FILTER_EURUSD.rann_RannForex,M1: total time from login to stop testing 0:00:00.967 (including 0:00:00.140for history data synchronization)
Core 1322 Mb memory used including 36 Mb of history data, 64 Mb of tick data
是的，但在你的情况下，"快速 "的概念是非常相对的。 对于用户来说，请求一个条形数组是一回事--他只是复制了一个内存区域，或者请求一个特定的时间序列，那么这也是一个简单的数据复制，步长不变，等于结构的大小。而另一件事是在每个数字上进行额外的计算和转换。
尽管就我个人而言，我更希望有一个压缩的历史，这样就不会浪费内存，因为无论如何我都要组织自己的数组来存储它。所以我愿意容忍一点延迟。但其他大多数用户会因此把你撕成碎片 )
p.s. 虽然在理想情况下，在终端有这样一个选项是很好的，可以选择在内存中存储历史的模式。例如，如果系统的内存很少，但有一个快速的处理器，这将是非常有用的。
好吧，看看。我刚刚测量了我的SDD的写入和读取速度。结果发现，8个字节（1种类型的值为双倍或日期时间或长）的写入和读取时间~48 ns。根据我的计算，从包装好的阵列中读取8字节信息的时间是1-2ns。因此，虽然我们在访问结构元素时损失了1-2纳秒，但在从磁盘写入和读取时，我们获得了48*0.8=38纳秒。此外，我们还有5倍的内存和磁盘空间的节省。 我甚至对硬盘也保持沉默。
好吧，看看。我刚刚测量了我的SDD的读和写速度。事实证明，8个字节（1种类型的值为双倍或日期时间或长）的写入和读取时间~48ns。根据我的计算，从包装好的阵列中读取8字节信息的时间是1-2ns。因此，虽然我们在访问结构元素时损失了1-2纳秒，但在从磁盘写入和读取时，我们获得了48*0.8=38纳秒。此外，我们有5倍的内存和磁盘空间节省。 我甚至不说硬盘。
我不与之争论。4年前，我们曾与Renat讨论过这个话题，当时SSD还很不常见，绝大多数用户都坐在慢速HDD上。所以我（以我的SSD为例）试图说服他，HDD的运行是系统中最慢的环节，我们应该尽量减少从它那里消耗的数据量，而不是反过来。 但是他有这样的论点：没有必要用额外的工作来加重CPU的负担，而且你们都是傻瓜，什么都不懂，等等。总的来说，一切如常 )
诚然，如今SSD明显加速了。
事实证明，写和读的时间是8个字节
关于交易、自动交易系统和交易策略测试的论坛
虫子，虫子，问题
fxsaber, 2018.09.10 21:28
首先，优化日志。
Tester optimization finished, total passes 714240 Statistics optimization done in 7 hours 31 minutes 06 seconds Statistics local 714240 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%) Core 1 connection closed Core 2 connection closed Core 3 connection closed Core 4 connection closed Core 5 connection closed Core 6 connection closed Core 7 connection closed Core 8 connection closed Tester 714240 new records saved to cache file 'tester\cache\Test.FILTER_EURUSD.rann_RannForex.M1.20180226.20180909.40.2D734373DF0CAD251E2BD6535A4C6C84.opt'在这7.5小时内，固态硬盘的访问频率非常高。如果每一次都读取刻度线，那么在7.5小时内平均每秒钟读取26次。因此，如此疯狂的眨眼--超过70万的阅读量。
单次运行日志
如图所示，使用了~130K点和60K条（在测试仪中选择了 "整个历史 "模式）。即极少量的历史。
终端中的自定义符号的历史包含以下数量的历史数据
即在历史上的符号是非常少的，比测试仪使用。
ZS 看一下固态硬盘就知道了，真是太可惜了......Optimise的速度能有多快？奇怪的是，操作系统并没有缓存这些数据，因为在未压缩的情况下，这些数据不到7MB。
什么文件夹的终端通过mklink连接到RAM-disk，这样数据就不是从SSD读/写，而是从内存读/写？我愿意提供数据，说明这在优化过程中会带来什么样的速度提升。
是的，这就是档案。如果我理解正确的话，现在ticks和minute bars都是无包装存储的，即对于一个bar（MqlRates结构）来说是60字节，而对于一个tick（MqlTick结构）来说是52字节。
太可怕了!很久以前就必须对此采取一些措施。
我理解，压缩数组的主要问题是组织对每个数组元素的快速访问。
但是，即使我们只存储一个数组的第256个元素，并在其他元素中只存储未打包的元素的增量，我们可以看到，数组的大小将缩小4-5倍，每个元素的访问时间不会增加太多（可能是1-2纳秒），但它将节省巨大的磁盘保存和读取阵列的时间。
"在你面前，一切都已经被偷走了" (cz)
在一天的开始，它是一个完整的勾。然后出价和/或要价和/或炒家全额，如果有的话其他都是增量。平均每格10个字节。
由于对ticks的访问是严格按顺序进行的，所以安排对数组中每个元素的快速访问是没有问题的
一个大的要求是发布 "Tester\cache\*.opt "记录的来源。你可以从内容中看到，格式非常简单。
使用优化的结果 工作是非常需要的。谢谢你!
出于某种原因，测试器的性能随着交易数量 的增加而下降。专家顾问方面没有提及交易历史。
情况似乎并非如此。
在测试仪中，与 "所有历史 "模式相对应的时间间隔被记忆下来。我把历史记录添加到自定义符号 中，重新加载终端，与 "所有历史记录 "相对应的间隔仍然没有变化。
我不能改变默认模式，但如果我选择整个历史，我就手动设置整个历史。请纠正。
在标记的地方缺少一个叉子--删除缓存条目的相应行。
我做了很多优化工作。有些已经过期很久了。而且也没有删除这些选项的机制。有时你得到一个巨大的列表，并开始在不必要的变体中搜索。
因此，请考虑在图片中标记的地方打叉，删除不必要的数据。
执行过程中出错
结果：真：假：7：4
不同长度的琴弦怎么会突然相等呢？而使用StringCompare 进行比较会得到相反的==结果
谢谢你的帖子，我们已经改变了逐个字符字符串比较的行为。
以前的字符串是 以Z-字符串的形式进行比较（直到空字符），现在是以PASCAL-字符串的形式进行比较（考虑到长度）。
现有的带有 "正常 "字符串（内部没有Z字符）的代码不会受到这一变化的影响。