Новая версия платформы MetaTrader 5 build 2650: Фоновая загрузка графиков и улучшения в профилировщике MQL5-кода
Большая просьба применить эту Оптимизацию и к окну Алертов.
И я это просил несколько раз за последние 2-3 года.
Как и про высоту поля полного описания алерта.
И о том, что ширины столбцов не сохраняются после перезапуска терминала.
А про некруглые значения X и Y графиков многие говорили много лет.
- Общая активность ЦП [единица измерения, %] — общее количество "появления" функции в стеке вызовов.
- Собственная активность ЦП [единица измерения, %] — количество "пауз", которые произошли непосредственно внутри указанной функции.
Этот счетчик наиболее важен для определения "узких" мест, поскольку по статистике остановка чаще происходит в тех участках программы, которые требуют большего процессорного времени.
Прошу пояснить, для понимания корректной интерпретации анализа этих значений.
Если количество пауз, превышает количество появления функции в стеке вызовов,
то это означает что есть тормоза в этом месте? Я правильно понимаю?
И второй вопрос.
После завершения профилирования, и после анализа результатов, как привести редактор в исходное отображение?
То есть как убрать эти красные линии в редакторе. Сейчас приходится перезагружать ME.
Может для цветовых настроек редактора, ввести загрузку сохранённого файла? По типу шаблона.
А лучше шаблон для всего редактора, чтоб включал все сохранённые настройки.
Прошу пояснить, для понимания корректной интерпретации анализа этих значений.
Если количество пауз, превышает количество появления функции в стеке вызовов,
то это означает что есть тормоза в этом месте? Я правильно понимаю?
ИМХО, такого быть не может: общее количество встречаемости функции в каком-либо месте стека всегда больше или равно количеству пауз внутри самой функции.
Тормоза конкретной функции тем больше, чем больше количество пауз в ней.
По крайней мере, я так понял. В принципе, хотелось бы более подробной документации, в частности, как и от чего считаются проценты.
Почему нет"комиссий" в столбцах ??? а в истории оно постфактум....
ИМХО, такого быть не может: общее количество встречаемости функции в каком-либо месте стека всегда больше или равно количеству пауз внутри самой функции.
Тормоза конкретной функции тем больше, чем больше количество пауз в ней.
По крайней мере, я так понял. В принципе, хотелось бы более подробной документации, в частности, как и от чего считаются проценты.
Я думаю, что в одной функции могут же быть несколько пауз, в разным местах функции.
По сути как я понимаю,
Общая активность - это количество вызовов функции, т.е. счётчик.
Собственная активность - количество пауз в этой функции, то есть задержки, тормоза.
По этому и предположил, что количество пауз надо сравнивать с количеством вызовов.
То есть за одну единицу вызова функции, должна быть одна единица задержки, это норма.
Если пауз больше чем вызовов, значит есть тормоза.
Посмотрите на скрине выше на OrderSend. Пауз больше чем вызовов, по тому что функция ждёт ответ сервера. И эту особенность нужно учитывать.
По этому для OrderSend это норма, если пауз будет больше, это говорит что медленно приходит ответ от сервера, и надо бы поближе разместится по пингу.
- Terminal: Добавлена настройка "Заранее загружать данные графиков по открытым позициям и ордерам".
Для экономии трафика торговая платформа загружает ценовую историю по инструментам только в момент ее фактического запроса, например, при открытии графика или при запуске тестирования. Однако для активно используемых инструментов это может быть не всегда удобно. Если включить новую опцию, то графики инструментов, по которым у вас есть открытые позиции или отложенные ордера, будут обновляться в фоновом режиме каждый раз при запуске платформы. Таким образом, при открытии графиков вам не придется ждать дозагрузки данных, они будут сразу доступны для анализа.
Не лучший выход.
Данные графиков должны загружаться если фин инструмент есть в обзоре рынка.
Трейдеры работают не только с ордерами или позициями.Я думаю, что в одной функции могут же быть несколько пауз, в разным местах функции.
По сути как я понимаю,
Общая активность - это количество вызовов функции, т.е. счётчик.
Собственная активность - количество пауз в этой функции, то есть задержки, тормоза.
По этому и предположил, что количество пауз надо сравнивать с количеством вызовов.
То есть за одну единицу вызова функции, должна быть одна единица задержки, это норма.
Если пауз больше чем вызовов, значит есть тормоза.
Посмотрите на скрине выше на OrderSend. Пауз больше чем вызовов, по тому что функция ждёт ответ сервера. И эту особенность нужно учитывать.
По этому для OrderSend это норма, если пауз будет больше, это говорит что медленно приходит ответ от сервера, и надо бы поближе разместится по пингу.
Нет смысла гадать. Такое понимание может быть и правильным, но оно противоречит вышеприведенной официальной формулировке (может быть она неточна).
Когда в функции происходит пауза, эта функция есть в стеке вызовов и потому это должно отражаться увеличением общего счетчика. Про "счетчик вызовов" функции ничего не было сказано, упомянуты только счетчик появления на стеке и счетчик нахождения внутри функции.

- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
В пятницу 9 октября 2020 года будет выпущена обновленная версия платформы MetaTrader 5. Обновление содержит следующие изменения:
Для экономии трафика торговая платформа загружает ценовую историю по инструментам только в момент ее фактического запроса, например, при открытии графика или при запуске тестирования. Однако для активно используемых инструментов это может быть не всегда удобно. Если включить новую опцию, то графики инструментов, по которым у вас есть открытые позиции или отложенные ордера, будут обновляться в фоновом режиме каждый раз при запуске платформы. Таким образом, при открытии графиков вам не придется ждать дозагрузки данных, они будут сразу доступны для анализа.
Добавлены новые параметры
Как уже сообщалось в предыдущем обновлении, для профилирования теперь используется метод "Sampling". Профилировщик делает паузы в работе MQL-программы (~1000 раз в секунду) и собирает статистику того, сколько раз пауза пришлась на тот или иной участок кода. В том числе анализируются стеки вызовов, чтобы определить "вклад" каждой функции в общее время работы кода. В конце профилирования вы получаете информацию о том, сколько раз была выполнена пауза и сколько раз каждая из функций оказывалась в стеке вызовов:
Добавлена возможность отключения инлайнинга функций при профилировании
При компиляции MQL-программ осуществляется инлайнинг (встраивание) — код функций помещается непосредственно в место их вызова, что позволяет добиться существенного ускорения при работе. Однако это затрудняет профилирование функций. Чтобы получить отчет по "чистым" функциям, вы можете отключить инлайнинг при профилировании в настройках MetaEditor:
Обновлен дизайн отчета
Мы переработали отчет профилирования, а также представление информации профилирования в окне исходного кода. Дизайн стал более современным и привычным для пользователей Visual Studio.
Помимо этого добавилась возможность настраивать цвет рамки для окна подсказок по функциям.