Ошибки, баги, вопросы - страница 2775
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Нет, причину мы не нашли и вряд ли найдём без точного технического описания проблемы со стороны пользователя.
тех данных, что мы получили от Вас и от пользователя на форуме недостаточно
https://www.mql5.com/en/forum/342152
Правильно ли сообщается?
Это нормально или ошибка или ...?
Спасибо за ваше время.
https://www.mql5.com/en/forum/342152
Правильно ли сообщается?
Это нормально или ошибка или ...?
Спасибо за ваше время.
Это не ошибка, это стоимость синхронной команды к чарту
Это не ошибка, это стоимость синхронной команды к чарту
Спасибо за Ваш ответ.
Однако получить простое свойство, такое как CHART_SCALE или CHART_AUTOSCROLL, кажется очень дорогостоящим. Я удивлен.
Это не ошибка, это стоимость синхронной команды к чарту
Зачем нужна команда чарту, для того чтобы снять с него характеристики? Разве не существует просто таблицы характеристик всех чартов в памяти, с которой можно просто снять данные за считанные наносекунды вместо миллисекунд (даже не микросекунд!)
Понятно, что функции 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 будет требовать синхронизации потоков, а на это может потребоваться дополнительно время.
Особенно заметны задержки, когда параллельный поток производит постоянное обновление данных структуры чарта (например, когда пользователь перемещает окно чарта или прокручивает историю).
Скорее всего, для простоты и надежности используется один объект синхронизации для свей структуры данных чартов.
Можно попробовать улучшить скорость выполнения используя "сегментацию данных", однако с другой стороны теперь появляется возможность нарваться на дедлок, или недообновленные данные, или на замедление работы в других более критических местах.
В общем - лучше не трогать то, что и так стабильно работает.