Ошибки, баги, вопросы - страница 2776
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Это не ошибка, это стоимость синхронной команды к чарту
Зачем нужна команда чарту, для того чтобы снять с него характеристики? Разве не существует просто таблицы характеристик всех чартов в памяти, с которой можно просто снять данные за считанные наносекунды вместо миллисекунд (даже не микросекунд!)
Понятно, что функции ChartSetInteger, ChartSetDouble, ChartSetString являются асинхронными.
Но почему тогда функции ChartGetInteger, ChartGetDouble, ChartGetString ведут себя по скорости выполнения как асинхронные, тогда как они синхронные?
Если такой таблицы не существует в памяти и этим функциям нужно каждый раз тормошить чарт, для того чтобы он сгенерировал запрашиваемый параметр, тогда я ничего не понимаю.
Ведь иметь такую таблицу и поддерживать её в актуальном состоянии - это совсем не дорого. Реально несколько килобайт в памяти и малая доля микросекунды на обновление таблицы при изменении характеристик чарта.
Ильяс, скажите пожалуйста, чего я недопонимаю?
Но почему тогда функции ChartGetInteger, ChartGetDouble, ChartGetString ведут себя по скорости выполнения, как асинхронные, тогда когда они синхронные?
У вас какое-то некорректное понимание терминов асинхронность и синхронность.
Когда говорят что функция асинхронная, то это значит, что она будет выполнена не в текущем потоке выполнения, а в каком-либо другом - параллельном.
Функция является асинхронной – это означает, что функция не дожидается выполнения команды, успешно поставленной в очередь указанного графика, а сразу же возвращает управление.
Изменение свойства произойдет только после обработки команды в очереди графика. Для немедленного выполнения команд в очереди графика нужно вызвать функцию ChartRedraw.
Вызов асинхронной как ChartSetInteger функции из основного потока быстрый, так как фактическое выполнение происходит в другом потоке.
С другой стороны вызов синхронной функции ChartGetInteger будет требовать синхронизации потоков, а на это может потребоваться дополнительно время.
Особенно заметны задержки, когда параллельный поток производит постоянное обновление данных структуры чарта (например, когда пользователь перемещает окно чарта или прокручивает историю).
Скорее всего, для простоты и надежности используется один объект синхронизации для свей структуры данных чартов.
Можно попробовать улучшить скорость выполнения используя "сегментацию данных", однако с другой стороны теперь появляется возможность нарваться на дедлок, или недообновленные данные, или на замедление работы в других более критических местах.
В общем - лучше не трогать то, что и так стабильно работает.
У вас какое-то некорректное понимание терминов асинхронность и синхронность.
Когда говорят что функция асинхронная, то это значит, что она будет выполнена не в текущем потоке выполнения, а в каком-либо другом - параллельном.
Вызов асинхронной как ChartSetInteger функции из основного потока быстрый, так как фактическое выполнение происходит в другом потоке.
С другой стороны вызов синхронной функции ChartGetInteger будет требовать синхронизации потоков, а на это может потребоваться дополнительно время.
Особенно заметны задержки, когда параллельный поток производит постоянное обновление данных структуры чарта (например, когда пользователь перемещает окно чарта или прокручивает историю).
Скорее всего, для простоты и надежности используется один объект синхронизации для свей структуры данных чартов.
Можно попробовать улучшить скорость выполнения используя "сегментацию данных", однако с другой стороны теперь появляется возможность нарваться на дедлок, или недообновленные данные, или на замедление работы в других более критических местах.
В общем - лучше не трогать то, что и так стабильно работает.
Ваше право, но, похоже, есть некоторые узкие места. Рынок сейчас закрыт, я запустил приведенный ниже код на 1 графике, больше ничего не работает. Он работает на VPS, где работает только MT5, и я не взаимодействовал с чартом / MT5 ни с чем, кроме как сделать снимок экрана. Время в мкс, 127 мкс в среднем, но пик составляет 43 995 мкс.
Господа разработчики!
Поправьте пожалуйста, если написал не в ту ветку. Есть предложения для удобства пользования и отладки, которые думаю, что будут для многих полезными, а для меня являются важными.
1. Увеличить длину строки OBJPROP_TOOLTIP для объектов (достаточно в 2 раза). Для стратегий с большим количеством графики текущей длины очень мало. Для отладки каждый раз приходится тратить время на то, чтобы все необходимые данные вместились. Потом же регулярно менять и(или) добавлять сокращения для потребителей.
2. Увеличить длину комментария к названиям входных параметров (достаточно в 2 раза). Для потребителя необходимы комментарии к входным параметрам. А при большом количестве, еще и удобно делать дополнительную нумерацию. Для оптимизации важно знать название переменной. В итоге все уместить в текущую длину часто не получается. Пример:
3. Разнообразить выбор столбцов в таблице результатов оптимизации - вплоть до того, чтобы вывести все из ENUM_STATISTICS, а пользователь уже выберет, что ему нужно. Ну очень бедный выбор для анализа. Просадка в % бесполезна при оптимизации с фиксированным объемом. Максимальной просадки в валюте по средствам и по депозиту нет возможности выбора. Иногда при оптимизации возникает сильный перекос между buy и sell позициями, но узнать это можно только после запуска одиночного тестирования. Приходится часто недостающие параметры выходить в поле результат (STAT_CUSTOM_ONTESTER). Но туда хочется вывести свои дополнительные критерии результата, а возможно вывести только один, с чем еще можно было бы мириться, если бы разнообразилось число столбцов стандартных критериев из ENUM_STATISTICS. В общем, приходится тратить много дополнительного времени на переоптимизации и анализ.
Спасибо!
Ваше право, но, похоже, есть некоторые узкие места. Рынок сейчас закрыт, я запустил приведенный ниже код на 1 графике, больше ничего не работает. Он работает на VPS, где работает только MT5, и я не взаимодействовал с чартом / MT5 ни с чем, кроме как сделать снимок экрана. Время в мкс, 127 мкс в среднем, но пик составляет 43 995 мкс.
Предположу, что пик - это отрисовка комментария чарта, в остальном, когда очередь чарта пуста, вызов функции ChartGetXXX (замечу, вызов с синхронизацией) занимает 0.13 миллисекунды
У вас какое-то некорректное понимание терминов асинхронность и синхронность.
Когда говорят что функция асинхронная, то это значит, что она будет выполнена не в текущем потоке выполнения, а в каком-либо другом - параллельном.
Вызов асинхронной как ChartSetInteger функции из основного потока быстрый, так как фактическое выполнение происходит в другом потоке.
С другой стороны вызов синхронной функции ChartGetInteger будет требовать синхронизации потоков, а на это может потребоваться дополнительно время.
Особенно заметны задержки, когда параллельный поток производит постоянное обновление данных структуры чарта (например, когда пользователь перемещает окно чарта или прокручивает историю).
Скорее всего, для простоты и надежности используется один объект синхронизации для свей структуры данных чартов.
Можно попробовать улучшить скорость выполнения используя "сегментацию данных", однако с другой стороны теперь появляется возможность нарваться на дедлок, или недообновленные данные, или на замедление работы в других более критических местах.
В общем - лучше не трогать то, что и так стабильно работает.
Если зажать кнопку PrtScr и перемещать окно чарта по кругу - это вызывает жуткие задержки до 5 сек slow motion.
Однако, если выполнять снимок экрана только окна программы terminal.exe через ALT + PrtScr - ни каких задержек нет.
Судя по встроенному сервису VPS, опыт этого дела имеется.
I will assume that the peak is the rendering of the chart comment, otherwise, when the chart queue is empty, the call to the ChartGetXXX function (note, the call with synchronization) takes 0.13 milliseconds
Нет, Ильяс, похоже, без комментариев на графике. Я буду использовать журналы и публиковать его.
Изменить: Здесь результат, никакого взаимодействия с графиком или MT5 или Windows, после запуска, кроме как для копирования журнала. Только 1 график, никакое другое программное обеспечение не работает в системе. Пик меньше, но все же очень важен по сравнению со средним. (µs)
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Количество = 7440
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Мин = 37
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Макс = 17776
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Avg = 147
Нет, Ильяс, похоже, без комментариев на графике . Я буду использовать журналы и публиковать его.
Изменить: Здесь результат, никакого взаимодействия с графиком или MT5 или Windows, после запуска, кроме как для копирования журнала. Только 1 график, никакое другое программное обеспечение не работает в системе. Пик меньше, но все же очень важен по сравнению со средним. (µs)
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Количество = 7440
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Мин = 37
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Макс = 17776
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Avg = 147
Обновить :
Максимальный пик теперь серьезно увеличен:
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Количество = 23520
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Мин = 33
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Макс = 81011
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Avg = 149