Ошибки, баги, вопросы - страница 2780
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Шаги для воспроизведения:
Невозможно не сказать Спасибо за такую работу! Надеюсь, по другим багам когда-нибудь получится что-то подобное.
Не поревете, давно-давно уже ответил:
К сожалению, выхлоп оказался не то что нулевым, а отрицательным...
Ну почему же отрицательным…
Ну не догнал с первого раза, ну не догнал со второго, но с третьего-то догнал.
Ну что поделать, если я такой тугой. В этом же нет Вашей вины.
Поэтому, не обижайтесь, Сергей.
У вас какое-то некорректное понимание терминов асинхронность и синхронность.
Когда говорят что функция асинхронная, то это значит, что она будет выполнена не в текущем потоке выполнения, а в каком-либо другом - параллельном.
Вызов асинхронной как ChartSetInteger функции из основного потока быстрый, так как фактическое выполнение происходит в другом потоке.
С другой стороны вызов синхронной функции ChartGetInteger будет требовать синхронизации потоков, а на это может потребоваться дополнительно время.
Особенно заметны задержки, когда параллельный поток производит постоянное обновление данных структуры чарта (например, когда пользователь перемещает окно чарта или прокручивает историю).
Скорее всего, для простоты и надежности используется один объект синхронизации для свей структуры данных чартов.
Можно попробовать улучшить скорость выполнения используя "сегментацию данных", однако с другой стороны теперь появляется возможность нарваться на дедлок, или недообновленные данные, или на замедление работы в других более критических местах.
В общем - лучше не трогать то, что и так стабильно работает.
Нет. Методы Get являются синхронными, но их можно сгруппировать и выполнить одновременно, поэтому вызов метода 1 Get или 100 почти одинаков.
Методы set являются асинхронными, но они также могут быть сгруппированы для большей эффективности.
Таким образом, всегда лучше группировать «Задать вызовы вместе» и «Получать вызовы вместе», а не «Получить / установить / получить / установить / получить / установить».
Асинхронные вызовы более эффективны, если вызывающий поток не заблокирован во время выполнения функции, но вы потеряете эти преимущества, если смешаете Get и Set.
Надеюсь, это поможет, несмотря на перевод.
Как я понял - Get синхронные, т.к. возвращают запрошенный результат. Но если в очереди есть асинхронные Set, то с ними приходится синхронизироваться.
Если в очереди только Get-ы, то задержек нет.
Спасибо всем. Потихоньку начинаю въезжать.
Теперь вырисовывается истинная картина таких задержек.
Как я понимаю (поправьте, пожалуйста, если не так):
При вызове метода Get из основного потока происходят запрос потоку самого чарта, который выполняется параллельно основному. Но поток чарта управляется непосредственно с основного потока методами Set и основной поток должен и так знать текущую характеристику чарта, но он только не знает текущее состояние потока чарта и не уверен, выполнены ли последние команды. Именно поэтому и происходит этот запрос, чтобы убедиться, что все предыдущие команды отработаны. А так-как метод Get синхронный, то он ожидает пока не придет ответ с параллельного потока чарта. Именно это является причиной задержек.
Если я ничего не напутал, то возникает вопрос:
Почему нельзя сделать так, чтобы параллельный поток докладывал основному потоку о том, что его команда выполнена и тогда основной поток отмечал бы команду выполненной и обновлял бы свою внутреннюю таблицу характеристик чарта? А на запрос Get бы выдавал данные из этой таблицы без запросов а параллельный поток. А в дополнение можно было бы еще передавать флаг о том, что ещё имеются невыполненные команды параллельному потоку чарта или все команды выполнены, чтобы понимать текущее состояние чарта. При такой схеме задержек не будет.
Примерно подобный механизм у меня реализован в классе iCanvas.
Вот демонстрирующий этот механизм индикатор, когда для связывания пиксельных координат канваса со временем и ценой чарта существует невероятно медленная функция ChartXYToTimePrice и создается ее аналог функция XYToTimePrice, которая обновляет свои внутренние статические переменные при наступлении события CHARTEVENT_CHART_CHANGE, и вычислет запрашиваемые параменты исходя из данных этой статической таблицы параметров чарта.
Спасибо всем. Потихоньку начинаю въезжать.
...Это верно. И, как сказал Ренат, кеш-систему необходимо реализовать на стороне mql. Возможно, это могло бы быть реализовано на стороне платформы, но это поставило бы под угрозу достижение наиболее производительной из возможных многопоточных архитектур.
Понятно.
Тем лучше для тех, кто понимает как реализовать эту кэш-систему, и хуже для тех, кто не понимает этого.
Постараюсь на аналогии, если уж и так не получится, значит так и быть.
Все очень утрировано и не правда, но все же.
Есть вы - заказчик, который определяет и приносит художнику краски, и есть художник, который использует принесенные вами краски и рисует ими на полотне.
После того, как вы принесли краски, вы свободны и можете заниматься своими делами: робота, дом, учеба, ....
Так же вы можете в произвольный момент прийти к художнику и проинспектировать результат работы.
Однако, если вы пришли проводить инспекцию, а художник в этот момент рисует, вам придется ждать, пока он не завершит свою работу.
Самый оптимальный способ взаимодействия - принести художнику все краски, которые необходимы, приказать рисовать, а затем пойти заниматься своими делами.
Уже в конце, если нужно, прийти к художнику на инспекцию столько раз сколько необходимо - доступ к полотну будет свободен.
Самый неоптимальный способ взаимодействия - приносить художнику краску по одной и сразу же требовать результат, каждый раз ожидая когда художник завершит свое дело.
В чем проблема в 2485 по сравнению с 2009 билдом:
Художник переехал к вам поближе, время на дорогу для инспекции стало тратиться меньше, что плюс.
Однако художник начал тратить на "подработку" на стороне очень много времени.
Он и раньше брал "подработки" с такой же частотой, однако сейчас попадая на выполнение художником "подработки" приходится уж слишком долго ждать завершение работы.
Понятно.
Тем лучше для тех, кто понимает как реализовать эту кэш-систему, и хуже для тех, кто не понимает этого.
Самый оптимальный способ взаимодействия - принести художнику все краски, которые необходимы, приказать рисовать, а затем пойти заниматься своими делами.
Уже в конце, если нужно, прийти к художнику на инспекцию столько раз сколько необходимо - доступ к полотну будет свободен.
По моему разумению самым оптимальным является договориться с художником, что как только он закончит какую-то очередную картину, то он сразу отметит выполненную конкретную работу у себя на сайте, который доступен для просмотра заказчику, а так же договориться, чтобы он на сайте указывал свой текущий статус - занят он подработками или свободен.
И тогда заказчит будет знать, какая картина готова, а какая нет без визита к художнику, и занят ли в данный момент художник или свободен и ему можно посылать очередное задание. И не нужно будет мотаться зря с инспекцией. Это сэкономит время и нервы как заказчику, так и художнику.
1) По моему разумению самым оптимальным является договориться с художником,
2) что как только он закончит какую-то очередную картину,
3) то он сразу отметит выполненную конкретную работу у себя на сайте, который доступен для просмотра заказчику,
4) а так же договориться, чтобы он на сайте указывал свой текущий статус - занят он подработками или свободен.
5) И тогда заказчит будет знать .... занят ли в данный момент художник или свободен и ему можно посылать очередное задание.
6) И не нужно будет мотаться зря с инспекцией. Это сэкономит время и нервы как заказчику, так и художнику.
1) Художник не знает ваши планы и вы тоже не знаете будущего...
2) Нет картин, есть одно полотно на котором идут все манипуляции и "подработки".
3) Вводить в аналогию процессы ни как не связанные с первоисточником - не понимание сути того, что такое аналогия и для чего она нужна.
4) Художник не знает будущего и если вам потребуется приехать на инспекцию, то его статус может сто раз измениться во время дороги.
5) Привезти краски можно в любой момент, на это всегда тратится одинаковое число времени вне зависимости от статуса художника и его занятости.
6) Опять не понимание сути того, что такое аналогия и для чего она нужна...