Баг MQL5 при работе c доступом к таймсериям iClose/iOpen и т.д. - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Тогда подскажите, почему происходит заморозка у меня ? У меня отдача данных в OnTick замерзает до функции опроса индикаторовю Тоесть обновление CopyTime по M1 выступает в качестве тригера запускающего остальную обработку в OnTick, а до CopyTime ни каких функций или опросов индикатора.
И почему до 30-го билда таких проблем не было и с октября 2017 года всё работало отлично ?
Сделайте как я посоветовал, пожалуйста.
Иначе нужны полные материалы для 100% воспроизведения.Почему бы разработчикам не написать функцию гарантированного получения синхронизированного массива данных (по нескольким инструментам) чтобы люди не корячились и не тратили время понапрасну?
ведь МТ5 позиционируется как крутой и удобный инструмент, верно?
очень ждём...
Также всегда рекомендовалось, если работаете с чужим таймфреймом - то раз в минуту необходимо получать OHLC с этого таймфрейма (любая CopyXXXX функция). Это было всегда.
Раз в две минуты Слава говорил. Лень искать, но точно помню.
Почему бы разработчикам не написать функцию гарантированного получения синхронизированного массива данных (по нескольким инструментам) чтобы люди не корячились и не тратили время понапрасну?
ведь МТ5 позиционируется как крутой и удобный инструмент, верно?
очень ждём...
Да. Конструктор OnCalcuate на нужное количество символов и таймфреймов. Или помимо OnCalculate, ввести новый объект, например "МаinCalculate" максимум на 255 OnСalculate, в котором живут объекты OnCalculate - кому не надо, пользуется по старому одним OnCalculate, кому нужно mtf и разные символы использует "MainCalculate". Первый и последний тик бара один для всех символов и совпадающих таймфреймов. Ведь уже сложилось и устаканилось OnCalculate, логично вывести все обращение к сторонним символам и таймфреймам через агрегацию OnCalculate без других функций посредников к таймфреймам и символам.
Задумайтесь, откуда будут доступны данные (тем более гарантированные), когда ваши индикаторы безбожно тормозят прием/наложение тиков, затрачивая на один тик сотни миллисекунд или даже секунд. В результате никакого CPU не хватает вовремя обрабатывать тики, что выливается в накапливающийся дефицит и соответствующую затормозку истории чарта.
Когда вы просите "гарантированно дайте", вероятнее всего это запрос "ничего не хочу знать, хочу продолжать писать как хочу, не хочу думать о производительности и блокировках, просто дайте"?
Когда вам доступны миллионы баров, то задумывайтесь о производительности своих и чужих индикаторов. Плохо написанный и дорогущий индикатор запросто может затормозить обновление чартов своего символа.
Для начала начните замерять в микросекундах время отработки OnCalculate. Потом разделите 1 секунду на среднее время отработки тика, чтобы получить максимальную пропускую способность индикатора в тиках за секунду.
Это сразу отрезвляет.
Раз в две минуты Слава говорил. Лень искать, но точно помню.
Я помню, но пользую всегда 1 минутный интервал. Так надежнее.
Вы меня извините, но в данном случае глубина истории по таймфрейму М15 была 120 баров и что, это уже критично для MQL5?
Вы не предоставили ни одного воспроизводимого материала.
Почему функции доступа к чужим данным будут тормозить при наличии на их символах тормозных индикаторов, я объяснил. Вы говорите о своем частном случае вызова, полностью игнорируя наличие других индикаторов на чартах. А именно с них и надо было начинать, тем более, что я четко об этом пишу.
Не занимайтесь демагогией и сравнительными заявлениями при полном отсутствии технических детелей и списков индкаторов с экспертами.
Дайте код для воспроизведения, пожалуйста.
***
Так как воспроизвести-то? Дайте пожалуйста данные для воспроизведения.
Весь кода конечно я не могу сюда вложить, а участок где возникает проблема, уже указывал, сделаю еще раз:
Или весь код или лучше ничего не говорите. Без полного кода простое сотрясание воздуха.
Задумайтесь, откуда будут доступны данные (тем более гарантированные), когда ваши индикаторы безбожно тормозят прием/наложение тиков, затрачивая на один тик сотни миллисекунд или даже секунд. В результате никакого CPU не хватает вовремя обрабатывать тики, что выливается в накапливающийся дефицит и соответствующую затормозку истории чарта.
Когда вы просите "гарантированно дайте", вероятнее всего это запрос "ничего не хочу знать, хочу продолжать писать как хочу, не хочу думать о производительности и блокировках, просто дайте"?
Когда вам доступны миллионы баров, то задумывайтесь о производительности своих и чужих индикаторов. Плохо написанный и дорогущий индикатор запросто может затормозить обновление чартов своего символа.
Для начала начните замерять в микросекундах время отработки OnCalculate. Потом разделите 1 секунду на среднее время отработки тика, чтобы получить максимальную пропускую способность индикатора в тиках за секунду.
Это сразу отрезвляет.
Не всегда нужна супер скорость, удобство работы также очень важно, сейчас написание мультивалютных индикаторов представляет собой "закат солнца вручную", даже в мт4 было проще потому что там всегда можно было получить через i-функции, пусть медленно, но получить, а в мт5 данные то есть то нет, и нужно ещё самому городить специальный код.
Также нужно иметь в виду, что не все пользователи высококлассными программистами, некоторым просто нужен удобный и надёжный инструментарий, пусть он будет не сверхзвуковой, да и для портфельных систем такая скорость и не нужна обычно, и миллионы баров не нужны, и максимальная пропускная способность не критична в данном случае, важно чтобы он работал именно гарантированно и просто, собственно это ведь и есть фактор чтобы сделать продукт популярнее и доступнее.
Появление i-функций в мт5 в чем-то улучшило ситуацию, но не решило проблему, нет возможности легко и просто взять и получить синхронизированный массив по нескольким инструментам, возможно это не всем нужно, возможно даже это не в приоритетах, я могу это понять, но тем не менее есть и такая задача.
Функция: GetSyncData
Вход: перечень инструментов, таймфрейм, диапазон баров и/или диапазон дат
Выход: массив с элементами MqlRates чтобы индексы всех инструментов соответствовали одному времени