Ошибки, баги, вопросы - страница 2099
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ребят, надоело в андроиде в мт5 постоянно вводить логин и пароль от www.mql5.com
Почему они постоянно слетают ???
У меня тоже спрашивает регулярно, но я не ввожу логин/пароль, а просто жму кнопку Назад, и оказывается, что он залогинен.
Почему такая весьма полезная функция как ChartXYToTimePrice() такая дорогая по времени выполнения?
Я написал функцию - аналог XYToTimePrice() и она работает гораздо быстрее. До нескольких сотен раз быстрее.
Так там же еще и ChartID_in с SubWindow_out в оригинале. Сделайте полный аналог.
Так там же еще и ChartID_in с SubWindow_out в оригинале. Сделайте полный аналог.
Добавить ChartID_in и SubWindow_out совсем не сложно. Но я не преследую цель создать полный аналог, а лишь создал эту функцию, чтоб показать тормознутость ChartXYToTimePrice().
но правда для моей функции необходим еще дополнительный параметр id события. И пока эта функция более менее одинаково работает с оригиналом при толщине свечи один пиксель, но можно ее доработать, если есть необходимость.
Добавить ChartID_in и SubWindow_out совсем не сложно. Но я не преследую цель создать полный аналог, а лишь создал эту функцию, чтоб показать тормознутость ChartXYToTimePrice().
но правда для моей функции необходим еще дополнительный параметр id события. И пока эта функция более менее одинаково работает с оригиналом при толщине свечи один пиксель, но можно ее доработать, если есть необходимость.
А еще я заметил странную особенность ChartXYToTimePrice. Время ее выполнения прямо пропорциональна количеству бар на графике.
Это говорит о "странности" алгоритма её вычисления. А именно о циклическом суммировании, что весьма странно для оптимального решения подобной задачи.
Скорость же функции XYToTimePrice одинакова вне зависимости от количества бар.
И, по правде сказать, скорость выполнения функций ChartGetInteger и ChartGetDouble тоже явно невероятно завышена и имеет очень странные особенности. Например функция
выполняется в 20-100 раз быстрее функции:
если МAX стоит после MIN:
но если поменять их местами, ситуация будет обратной.
т.е. вроде логично - такая же функция, которая вычисляется повторно, использует уже вычисленные и сохраненные данные из предыдущего вызова функции. Но просто это говорит о том, что происходят какие то сумасшедшие вычисления и создания кучи промежуточных данных и может быть даже массивов для вычисления простого значения double максимальной (или минимальной) цены графика, которая наверняка уже и так сидит уже в какой-нибудь переменной и нужно просто ее взять.
Хотя я и не исключаю, что данный эффект происходит из-за какой-то особенности профилирования и носит фейковый характер. Но тормознутость этих функций не фейковая.
можно ее доработать, если есть необходимость.
Наверное, все же правомерно говорить о корректности сравнения скоростных характеристик двух функций, когда их результаты совпадают. Допилите, пожалуйста.
Ребят, надоело в андроиде в мт5 постоянно вводить логин и пароль от www.mql5.com
Почему они постоянно слетают ???
Напишите в сервисдеск. Приложите логи. Спасибо.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Ошибки, баги, вопросы
fxsaber, 2017.10.04 09:13
Много раз об этом писали. Не правят почему-то.
А еще я заметил странную особенность ChartXYToTimePrice. Время ее выполнения прямо пропорциональна количеству бар на графике.
Это говорит о "странности" алгоритма её вычисления. А именно о циклическом суммировании, что весьма странно для оптимального решения подобной задачи.
Скорость же функции XYToTimePrice одинакова вне зависимости от количества бар.
И, по правде сказать, скорость выполнения функций ChartGetInteger и ChartGetDouble тоже явно невероятно завышена и имеет очень странные особенности. Например функция
выполняется в 20-100 раз быстрее функции:
если МAX стоит после MIN:
но если поменять их местами, ситуация будет обратной.
т.е. вроде логично - такая же функция, которая вычисляется повторно, использует уже вычисленные и сохраненные данные из предыдущего вызова функции. Но просто это говорит о том, что происходят какие то сумасшедшие вычисления и создания кучи промежуточных данных и может быть даже массивов для вычисления простого значения double максимальной (или минимальной) цены графика, которая наверняка уже и так сидит уже в какой-нибудь переменной и нужно просто ее взять.
Хотя я и не исключаю, что данный эффект происходит из-за какой-то особенности профилирования и носит фейковый характер. Но тормознутость этих функций не фейковая.
Тормознутось функций запроса данных о чарте заключается в способе отправки и получения информации, а не в самой реализации. Сама реализация этих функций примитивна и не зависит от количества баров на графике.
Но так как график - это объект, информация от которого раздаётся по многим источникам, то всё управление построено на очередях сообщений. Пока предыдущий запрос не обработан, следующий ждёт.
Но если у вас идут подряд несколько запросов к одному и тому же графику, то вот эти последующие запросы исполняются очень быстро. Потому что между ними и первым запросом никто не успел вклиниться.
Тормознутось функций запроса данных о чарте заключается в способе отправки и получения информации, а не в самой реализации. Сама реализация этих функций примитивна и не зависит от количества баров на графике.
Но так как график - это объект, информация от которого раздаётся по многим источникам, то всё управление построено на очередях сообщений. Пока предыдущий запрос не обработан, следующий ждёт.
Но если у вас идут подряд несколько запросов к одному и тому же графику, то вот эти последующие запросы исполняются очень быстро. Потому что между ними и первым запросом никто не успел вклиниться.
Пусть так. Но от осознания этого легче не становится. Слава, ну поймите простого программиста правильно. Мой пример тестового индикатор из предыдущих сообщений четко показывает что среднее время выполнения запроса ChartXYToTimePrice() это 5000 - 10000 микросекунд ( при толщине свечи 1 пиксель и стандартном окне в MT на FullHD экране). Что можно сделать за такое время?
Ну вот, например, за это время можно сформировать изображение в том же экране из 500 закрашенных окружностей и вывести их на экран:
Пусть даже существует очередь, но почему так долго в очереди стоит?
На одной чаше весов попиксельное формирование 500 окружностей с выводом их на экран, а на другой простой запрос о двух цифрах. И весит это одинаково.
Вот сидит простой программист, чешет репу и пазлы сложить не может.
Пусть так. Но от осознания этого легче не становится. Слава, ну поймите простого программиста правильно. Мой пример тестового индикатор из предыдущих сообщений четко показывает что среднее время выполнения запроса ChartXYToTimePrice() это 5000 - 10000 микросекунд ( при толщине свечи 1 пиксель и стандартном окне в MT на FullHD экране). Что можно сделать за такое время?
Ну вот, например, за это время можно сформировать изображение в том же экране из 500 закрашенных окружностей и вывести их на экран:
Пусть даже существует очередь, но почему так долго в очереди стоит?
На одной чаше весов попиксельное формирование 500 окружностей с выводом их на экран, а на другой простой запрос о двух цифрах. И весит это одинаково.
Вот сидит простой программист, чешет репу и пазлы сложить не может.
Вы почувствовали разницу между синхронной командой и асинхронной.