Сравнение скорости тестирования в MetaTrader 4 и MetaTrader 5 - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Про скорость тестирования - разработчиками на заметку.
Тестирую сейчас достаточно простой советник период - весь прошлый год режим OHLC на M1. Проход пролетал секунд за 10.
Поскольку точки останова в тестере не работают - пришлось перетащить свою систему логов с мт4 на мт5 и все умерло. То что пролетало за 10 секунд стучит уже 4 часа и не прошло и трети.
Причем что напрягает - загрузка процессора стоит на уровне 2-4 %. Поковырялся - что же дает такие тормоза - выяснилось команда FileFlush( ), которая выталкивала контекст в файл после каждой записи строки
для оперативной визуализации. Закомментарил и все пошло опять быстро. Но как говорится - осадочек остался ))) На mt4 таких финтов не наблюдал. (стоит билд 674)
Поковырялся - что же дает такие тормоза - выяснилось команда FileFlush( ), которая выталкивала контекст в файл после каждой записи строки
Но как говорится - осадочек остался ))) На mt4 таких финтов не наблюдал. (стоит билд 674)
по этой функции все вопросы к мелкомягким. она действительно очень медленная, и это не от МТ5 зависит.
А вот как раз очень спорно.
Во-первых она по идее не должна грузить проц практически совсем. Т.к. основная работа должна вестись с веником (хотя есть еще кэширование...)
Во-вторых никто не видел имплементацию этой функции, так что кивать на мелко-мягких немного эээ странно.
Можно сравнить с прямым вызовом WinAPI'шной функции FlushFileBuffers и тогда уже делать выводы.
А вот как раз очень спорно.
Во-первых она по идее не должна грузить проц практически совсем. Т.к. основная работа должна вестись с веником (хотя есть еще кэширование...)
Во-вторых никто не видел имплементацию этой функции, так что кивать на мелко-мягких немного эээ странно.
ну а какая еще может быть имплементация, кроме как обращение к WinApi?
я на своей шкуре прочуствовал весь тормоз винапишной функции. поэтому выводы мои однозначны.
ну а какая еще может быть имплементация, кроме как обращение к WinApi?
Какая угодно.
А с вот этой штукой -- FILE_FLAG_NO_BUFFERING с FILE_FLAG_WRITE_THROUGH -- пользовал? Это вроде как замена вышеописанному.
Какая угодно.
А с вот этой штукой -- FILE_FLAG_NO_BUFFERING с FILE_FLAG_WRITE_THROUGH -- пользовал? Это вроде как замена вышеописанному.
Не ферштейн WinAPI (ну почти), но с FileFlush() надо чё-то делать. Я в прошлом году на эти грабли наступал - тормоз запредельный.
Причём если мне не изменяет память - в чётвёрке всё летает.
Учитывая, что в MT5 никаких средств для обмена данных между потоками не предусмотрены (кроме событий, куда пихать не всегда уместно), хорошо бы, чтоб файловый обмен не тормозил. И FileFlush при таком обмене необходим, чтоб данные реально на диск сбрасывались, а не зависали в буфере. Map-файлы это здорово, но это не штатное средство и требует усилий для освоения и использования, для простых экспериментальных систем желательно иметь вариант штатный и попроще.
MetaDriver:
Map-файлы это здорово, но это не штатное средство и требует усилий для освоения и использования, для простых экспериментальных систем желательно иметь вариант штатный и попроще.
Mapping никакого отношшения к сохранению не имеет. Это просто отображение (или проекция) файла в памяти.
Я в курсе. Наверху, всё что я про маппинг писал - это исключительно в контексте обмена информацией между потоками (скриптами, экспертами, индикаторами).
Для просто сохранения FileFlush нафиг не сдался (по крайней мере в тестере).
--
Ну вот и Ренат о том же.