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
滴答声并不存储在RAM中。根据我的理解，它们是根据需要零散地下载的。
如果通过实际的蜱虫，那么是的。
在一个单一的通道中，你可以查看统计数据，了解有多少内存被花在ticks存储上。优化时，每次存储在内存中的数据不超过320兆。其余的则储存在磁盘上。
我们现在正在考虑一个解决方案，将所有ticks保存在共享内存中，这样所有的本地代理都可以从这个内存中读取。那么就不会有磁盘访问了，优化也会更快。
如果按实际的虱子，是的。
有可能看到统计数字，即在单次传递中，有多少内存被花在了ticks存储上。优化后，每次存储在内存中的容量不超过320兆。其他东西都在磁盘上。
我们现在正在考虑一个解决方案，将所有的ticks保存在一个共享内存中，这样所有的本地代理都可以从这个内存中读取。那么就不会有磁盘访问，优化也会更快。
是的，这就是档案。如果我理解正确的话，现在的ticks和minute bars是在磁盘上和内存中无包装存储的，即bar（MqlRates结构）是60字节，tick（MqlTick结构）是52字节。
太可怕了!很久以前就必须对此采取一些措施。
我理解，压缩数组的主要问题是组织对每个数组项的快速访问。
但是，即使我们只保留数组中每256个元素的解包，而在其他元素中只存储解包元素的增量，我们可以看到，数组的大小将减少4-5倍，每个元素的访问时间不会增加很多（可能是1-2纳秒），但它将节省大量的从磁盘保存和读取数组的时间。
为什么在优化过程中，SSD不断被寻址（指示灯高速闪烁）？
这就是为什么我不使用ticks，我使用对数数据结构（我已经说过了），在一个特定的时间，由几千个ticks组成，然后是几千个分钟条，2000个M2，2000个M5 ，M10，M30，H1，H3，H6，H12，D1，W1...所有MN1酒吧。
这种完整的历史数据结构在任何时刻都会形成，时间不到一毫秒，在RAM中只占用1.5MB（实际上甚至不在RAM中，而是在处理器的高速缓存中）。而所有的算法，为这个结构接地气，就会飞起来。
毕竟，我们的视力是建立在同样的对数尺度上的：我们看得越远，就越注意不到小细节。
当在不远的将来，计算机将只有一个物理内存设备（硬盘、内存、处理器缓存），即处理器缓存里有13个零时，那么我也会改用滴答的方式。）
...
虽然，也许是我出了问题，因为有了这样的数据结构在优化过程中，灯泡也会闪动。毕竟，蜱虫仍然会被加载 :( )
如果按实际的虱子，是的。
你可以看到统计数字，即在单个通道中存储ticks所花费的内存是多少。优化后，每次存储在内存中的容量不超过320兆。其他东西都在磁盘上。
我们现在正在考虑一个解决方案，将所有ticks保存在共享内存中，这样所有的本地代理都可以从这个内存中读取。那么就不会有对磁盘的访问，优化也会更快。
首先，让我们从优化日志开始
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。
但是，即使我们只存储一个数组的第256个元素，并且只存储未打包元素的增量，一个数组的大小将减少4-5倍，而每个元素的访问时间不会大大增加（可能是1-2纳秒），但它将节省大量从磁盘保存和读取数组的时间。
雷纳特对你来说是不够的 )有多少次建议优化历史存储。特别是没有任何东西需要花在压缩上（这是最耗费资源的部分），因为数据最初来自于服务器的压缩，只有不断使用的cache被保持解压......但是，这就是讲座总是出现的原因：如果你不能买一个更大或更快的硬盘，那么在MT上就没有什么可做的。 而缓慢的VPS总是因为某种原因被提及。
雷纳特对你来说是不够的 )有多少次建议优化历史存储。特别是没有任何东西需要花在压缩上（这是最耗费资源的部分），因为数据最初是从服务器上压缩过来的，只有不断使用的缓存是以未压缩的形式保留的......但是，这就是讲座总是出现的原因：如果你不能买一个更大或更快的硬盘，那么在MT上就没有什么可做的。 而缓慢的VPS总是因为某种原因被提及。
再次，打包数组的主要问题是组织对任何数组元素 的快速访问，而不是按顺序读取它们。这就是为什么这里需要一种不同的压缩格式（或者说甚至是存储格式），是的，这样就不需要解压和打包。zip、png等的~10倍压缩当然是不行的，但我认为5倍是可以的。
嗯，真的，如果我们考虑一下，在MqlRates中，8*4=32个字节被分配用于存储一分钟的小节信息（同时只存储一分钟的小节），尽管在99%的情况下，这些数值相差不到一个字节的信息，即8+1+1+1=11个字节几乎足够，即使不与之前的小节绑定。而时间在99%的情况下与前一个值正好相差60（即在99%的情况下，1比特的信息就足够了--60或不60）。而8个字节也被分配给了这个。
再次，打包数组的主要问题是组织对任何数组元素 的快速访问，而不是按顺序读取它们。这就是为什么这里需要一种不同的压缩格式（或者说甚至是存储格式），是的，这样就不需要解压和打包。当然，zip、png等不可能被压缩~10倍，但我认为5倍是可能的。
如果我们谈论的是磁盘上的存储，对特定项目的访问是没有意义的，因为文件操作本身的成本很高。 因此，一次就能读取一大块。 例如，酒吧历史文件是按年划分的，蜱虫是按月划分的。如果你的意思是将历史以打包的形式保存在内存中，不断地在飞行中解开每个元素，那么我担心它不会适合任何人。
我刚刚发明了一种存储格式，它可以存储256个MqlRates元素的块，平均需要2900个字节（块的大小将是浮动的），即2900/256= ~12字节将被分配给每个MqlRates结构，这比我想象的要少5倍。
对包装好的MqlRates结构的每个元素的访问都足够快（2-3次求和，2-3次检查，2-3次转移，即几乎不超过1纳秒）。
如果我们谈论的是存储在磁盘上，访问一个特定的元素是没有意义的，因为文件操作本身是有成本的。 因此，大块的文件被一次性读取。 例如，酒吧历史文件是按年分割的，刻度线是按月分割的。如果你的意思是将历史以打包的形式保存在内存中，不断地在飞行中解开每个元素，那么我担心它不会适合任何人。
它将以 "压缩 "格式存储在磁盘上，也以同样的格式读入内存。不会有向完整格式的转换，但在读取MqlRates结构的 特定元素时，只会有一个计算。而且，考虑到磁盘的工作将减少五倍，它的速度会快很多。
对打包好的MqlRates结构的每个元素的访问是相当快的
...
它将以 "压缩 "格式存储在磁盘上，并以同样的格式读入内存。不会有任何向完整格式的转换，而只是在读取MqlRates结构中 某一特定元素的时刻进行的计算。
是的，但在你的情况下，"快速 "的概念是非常相对的。 有一点是，用户要求的是一个条形数组，他只是复制了一段内存，或要求一些特定的时间序列，这也是一个简单的数据复制，步长不变，等于结构的大小。而另一件事是在每个数字上进行额外的计算和转换。
尽管就我个人而言，我更希望有一个压缩的历史，这样就不会浪费内存，因为无论如何我都要组织自己的数组来存储它。所以我愿意容忍一点延迟。但其他大多数用户会因此把你撕成碎片 )
p.s.不过，理想的情况是，在终端有这样一个选项，可以选择历史在内存中的存储方式，那就更好了。例如，如果系统的内存很少，但有一个快速的处理器，这将是非常有用的。