Если кастом обновлять каждый тик через CustomRatesUpdate, будет такой же рост размера файла. Это старая проблема. Для себя нашел решение через регулярное удаление и перезаливку всей истории кастома одним куском в генераторе. Занимает миллисекунды, файл возвращается к нормальным размерам.
Подтверждено и передано в MetaQuotes.
Владимир #:
Если кастом обновлять каждый тик через CustomRatesUpdate, будет такой же рост размера файла. Это старая проблема. Для себя нашел решение через регулярное удаление и перезаливку всей истории кастома одним куском в генераторе. Занимает миллисекунды, файл возвращается к нормальным размерам.
Да, я в результате тестов пришел к решению - с какой-то периодичностью удалить всю историю за последний год и залить одним куском, правда там не миллисекунды, а пару секунд получалось.Если кастом обновлять каждый тик через CustomRatesUpdate, будет такой же рост размера файла. Это старая проблема. Для себя нашел решение через регулярное удаление и перезаливку всей истории кастома одним куском в генераторе. Занимает миллисекунды, файл возвращается к нормальным размерам.
А о каком генераторе речь?
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
При работе с историей пользовательских символов MT5 столкнулся с проблемой сильного разрастания файлов .hcc.
В реальных условиях отдельные годовые файлы истории достигали нескольких гигабайт.
При непрерывной работе моего сервиса-криптомоста на 14 символах свободное место на диске начало уменьшаться примерно по 1 Гб в сутки.
Удалось воспроизвести этот эффект в небольшом изолированном тесте с использованием CustomRatesReplace().
Среда тестирования: MetaTrader 5, build 6230. Необходимо разрешить импорт DLL для получения размеров hcc файлов.
При трёхминутном тесте скрипт генерирует 180 искусственных M1-баров с последовательным временем открытия, фиксированными OHLC, объёмами и спредом.
Сравниваются два способа записи одних и тех же баров в пользовательские символы:
BULK — пакетная запись
Для каждой контрольной точки (30, 60, 90,120, 150 и 180 баров) создаётся новый пользовательский символ с пустой историей.
Все N баров записываются одним вызовом: CustomRatesReplace(symbol, first, last, bars)
Таким образом, каждый BULK-файл формируется независимо, ровно одним вызовом CustomRatesReplace.
SEQ — последовательная запись
Создаётся один пользовательский символ, в который те же бары записываются по одному, с интервалом в одну секунду.
Для каждого бара вызывается: CustomRatesReplace(symbol, bar.time, bar.time, one_bar)
После каждых 30 вызовов измеряется физический размер годового файла 2025.hcc.
На каждой контрольной точке оба варианта содержат одинаковое количество одинаковых M1-баров.
Размер .hcc измеряется непосредственно средствами Windows API (GetFileAttributesExW), а не оценивается по количеству баров.
Сравнение скорости роста размера файлов:
При пакетной записи размер .hcc растёт сравнительно медленно. При последовательной записи по одному бару наблюдается существенно более быстрый рост, причём разница между файлами увеличивается с каждой контрольной точкой.
После записи 180 баров:
BULK: 26 133 байта, один вызов CustomRatesReplace
SEQ: 1 026 564 байта, 180 вызовов CustomRatesReplace
Разница: 39 раз
Почему пришлось использовать CustomRatesReplace:
Изначально применялся CustomRatesUpdate(), однако при его совместной работе с CustomTicksAdd() обнаружилась потеря части M1-истории текущего дня.
Отдельный тест подтвердил проблему: CustomRatesUpdate() приводил к потере баров, а CustomRatesReplace() сохранял историю полностью, см. тему: https://www.mql5.com/ru/forum/517927
Поэтому пришлось перейти на CustomRatesReplace(), но возникла другая проблема — чрезмерное разрастание файлов .hcc при последовательной записи M1.