У вас там что-то сложное считается, что нужно именно по тикам делать пересчёт?
Где-то в другой теме есть тот код о котором здесь говорится. Я не пытался досконально разобраться в нём, но надо внимательно посмотреть не считается-ли вся история на каждом тике.
Что-то не сходится, бары не несколько раз в секунду приходят) и никак не пойму чем не устраивает таймер при такой постановке задачи, наверное вы просто не определились что вам надо в итоге.
Тики приходят сотни раз в секунду. Каждый раз вызывается oncalculate , дикий перегруз. Даже поставив тот код, которые мне рекомендовали всё таки перегруз. Хотя время вычисления индикатора 15-20 ms.
Таймер - не понимаю как туда засунуть данный цены. В oncalculate они передаются в параметрах.
Также мне непонятно если есть onCalcualate и OnTimer как избежать RaceCondition - когда одни и те же данные в двух разных местах правяться
Alexey Viktorov: Где-то в другой теме есть тот код о котором здесь говорится. Я не пытался досконально разобраться в нём, но надо внимательно посмотреть не считается-ли вся история накаждом тике.
Нет не считается вся история. Но и одного бара хватает чтобы он сдох если вызов больше пары раз в секунду. - Там относительно много разных вычисления
Тики приходят сотни раз в секунду. Каждый раз вызывается oncalculate , дикий перегруз. Даже поставив тот код, которые мне рекомендовали всё таки перегруз. Хотя время вычисления индикатора 15-20 ms.
Таймер - не понимаю как туда засунуть данный цены. В oncalculate они передаются в параметрах.
Также мне непонятно если есть onCalcualate и OnTimer как избежать RaceCondition - когда одни и те же данные в двух разных местах правяться
Нет не считается вся история. Но и одного бара хватает чтобы он сдох если вызов больше пары раз в секунду. - Там относительно много разных вычисления
в таймере можно к ценам обращаться по iClose... функциям
Если ваш код считает долго, то тики пропускаются же всё равно. Если такие долгие расчёты, может один -два раза на бар тогда? или на 0-м прям точные актуальные данные нужны ?
И да, вы говорите 15-20 мс, это не очень быстро для ОнТик, но в чём именно перегруз? может вы создаете в памяти новые данные на гигабайты, и значит дело не в скорости самих вычислений, в обращении с памятью.
и просто интересно на каком инструменте сотни раз в секунду тики?
в таймере можно к ценам обращаться по iClose... функциям
Если ваш код считает долго, то тики пропускаются же всё равно. Если такие долгие расчёты, может один -два раза на бар тогда? или на 0-м прям точные актуальные данные нужны ?
И да, вы говорите 15-20 мс, это не очень быстро для ОнТик, но в чём именно перегруз? может вы создаете в памяти новые данные на гигабайты, и значит дело не в скорости самих вычислений, в обращении с памятью.
и просто интересно на каком инструменте сотни раз в секунду тики?
ап: выделенное опять не сходится...
Время вычисления считал как умею : через разницу https://www.mql5.com/en/docs/common/gettickcount и печатаю её через comment(). Показывает обычно 16-45 ms. Наверное есть и прочие расходы - на отрисовку и прочее.Я уж не знаю где конкретно клины и узкие места.
Если бы тики просто пропускались и ладно . Но реальности что происходит когда много тиков - происходит полная рассихронизация( Последний MqlRates содержит устаревшие значения). Бары отрисовываются с запаздыванием на минуты и даже иногда десятки минут (а не 45 мс). Лечиться только перезапуском терминала. И если нагрузка большая то и после перегрузки тоже самое снова происходит
ES MINI дает легко сотни тиков в секунду в рабочую сессию (особенно в начале и конце).
Тики приходят сотни раз в секунду. Каждый раз вызывается oncalculate , дикий перегруз. Даже поставив тот код, которые мне рекомендовали всё таки перегруз. Хотя время вычисления индикатора 15-20 ms.
Таймер - не понимаю как туда засунуть данный цены. В oncalculate они передаются в параметрах.
Также мне непонятно если есть onCalcualate и OnTimer как избежать RaceCondition - когда одни и те же данные в двух разных местах правяться
Нет не считается вся история. Но и одного бара хватает чтобы он сдох если вызов больше пары раз в секунду. - Там относительно много разных вычисления
Возможно, вам это и нужно:
intOnCalculate(constint rates_total,
constint prev_calculated,
constdatetime &time[],
constdouble &open[],
constdouble &high[],
constdouble &low[],
constdouble &close[],
constlong &tick_volume[],
constlong &volume[],
constint &spread[])
{
//---if(rates_total-prev_calculated==0) // Если бар не новыйreturn(rates_total); // выходим и ничего не делаем дальше
........
........
Время вычисления считал как умею : через разницу https://www.mql5.com/en/docs/common/gettickcount и печатаю её через comment(). Показывает обычно 16-45 ms. Наверное есть и прочие расходы - на отрисовку и прочее.Я уж не знаю где конкретно клины и узкие места.
Если бы тики просто пропускались и ладно . Но реальности что происходит когда много тиков - происходит полная рассихронизация( Последний MqlRates содержит устаревшие значения). Бары отрисовываются с запаздыванием на минуты и даже иногда десятки минут (а не 45 мс). Лечиться только перезапуском терминала. И если нагрузка большая то и после перегрузки тоже самое снова происходит
ES MINI дает легко сотни тиков в секунду в рабочую сессию (особенно в начале и конце).
Поигрался побольше. Что интересно если засунуть асболютно этот же индикатор в эксперт и прогнать его то за 20 дней отработка происодит за 100 мс! Т.е. узкое место в том как происходит отработка и отрисовка индикаторов наложенных на график. Если сделать из эскперта без отрисовки( через strategy tester) , то всё значительно лучше
У вас там что-то сложное считается, что нужно именно по тикам делать пересчёт?
Где-то в другой теме есть тот код о котором здесь говорится. Я не пытался досконально разобраться в нём, но надо внимательно посмотреть не считается-ли вся история на каждом тике.
Что-то не сходится, бары не несколько раз в секунду приходят) и никак не пойму чем не устраивает таймер при такой постановке задачи, наверное вы просто не определились что вам надо в итоге.
Тики приходят сотни раз в секунду. Каждый раз вызывается oncalculate , дикий перегруз. Даже поставив тот код, которые мне рекомендовали всё таки перегруз. Хотя время вычисления индикатора 15-20 ms.
Таймер - не понимаю как туда засунуть данный цены. В oncalculate они передаются в параметрах.
Также мне непонятно если есть onCalcualate и OnTimer как избежать RaceCondition - когда одни и те же данные в двух разных местах правяться
Где-то в другой теме есть тот код о котором здесь говорится. Я не пытался досконально разобраться в нём, но надо внимательно посмотреть не считается-ли вся история на каждом тике.
Нет не считается вся история. Но и одного бара хватает чтобы он сдох если вызов больше пары раз в секунду. - Там относительно много разных вычисления
Тики приходят сотни раз в секунду. Каждый раз вызывается oncalculate , дикий перегруз. Даже поставив тот код, которые мне рекомендовали всё таки перегруз. Хотя время вычисления индикатора 15-20 ms.
Таймер - не понимаю как туда засунуть данный цены. В oncalculate они передаются в параметрах.
Также мне непонятно если есть onCalcualate и OnTimer как избежать RaceCondition - когда одни и те же данные в двух разных местах правяться
Нет не считается вся история. Но и одного бара хватает чтобы он сдох если вызов больше пары раз в секунду. - Там относительно много разных вычисления
в таймере можно к ценам обращаться по iClose... функциям
Если ваш код считает долго, то тики пропускаются же всё равно. Если такие долгие расчёты, может один -два раза на бар тогда? или на 0-м прям точные актуальные данные нужны ?
И да, вы говорите 15-20 мс, это не очень быстро для ОнТик, но в чём именно перегруз? может вы создаете в памяти новые данные на гигабайты, и значит дело не в скорости самих вычислений, в обращении с памятью.
и просто интересно на каком инструменте сотни раз в секунду тики?
ап: выделенное опять не сходится...Нет не считается вся история. Но и одного бара хватает чтобы он сдох если вызов больше пары раз в секунду. - Там относительно много разных вычисления
Если в момент вычисления приходят ещё несколько тиков, то они пропускаются. Следовательно вам надо как-то оптимизировать вычисления.
в таймере можно к ценам обращаться по iClose... функциям
Если ваш код считает долго, то тики пропускаются же всё равно. Если такие долгие расчёты, может один -два раза на бар тогда? или на 0-м прям точные актуальные данные нужны ?
И да, вы говорите 15-20 мс, это не очень быстро для ОнТик, но в чём именно перегруз? может вы создаете в памяти новые данные на гигабайты, и значит дело не в скорости самих вычислений, в обращении с памятью.
и просто интересно на каком инструменте сотни раз в секунду тики?
ап: выделенное опять не сходится...Время вычисления считал как умею : через разницу https://www.mql5.com/en/docs/common/gettickcount и печатаю её через comment(). Показывает обычно 16-45 ms. Наверное есть и прочие расходы - на отрисовку и прочее.Я уж не знаю где конкретно клины и узкие места.
Если бы тики просто пропускались и ладно . Но реальности что происходит когда много тиков - происходит полная рассихронизация( Последний MqlRates содержит устаревшие значения). Бары отрисовываются с запаздыванием на минуты и даже иногда десятки минут (а не 45 мс). Лечиться только перезапуском терминала. И если нагрузка большая то и после перегрузки тоже самое снова происходит
ES MINI дает легко сотни тиков в секунду в рабочую сессию (особенно в начале и конце).
Тики приходят сотни раз в секунду. Каждый раз вызывается oncalculate , дикий перегруз. Даже поставив тот код, которые мне рекомендовали всё таки перегруз. Хотя время вычисления индикатора 15-20 ms.
Таймер - не понимаю как туда засунуть данный цены. В oncalculate они передаются в параметрах.
Также мне непонятно если есть onCalcualate и OnTimer как избежать RaceCondition - когда одни и те же данные в двух разных местах правяться
Нет не считается вся история. Но и одного бара хватает чтобы он сдох если вызов больше пары раз в секунду. - Там относительно много разных вычисления
Возможно, вам это и нужно:
Время вычисления считал как умею : через разницу https://www.mql5.com/en/docs/common/gettickcount и печатаю её через comment(). Показывает обычно 16-45 ms. Наверное есть и прочие расходы - на отрисовку и прочее.Я уж не знаю где конкретно клины и узкие места.
Если бы тики просто пропускались и ладно . Но реальности что происходит когда много тиков - происходит полная рассихронизация( Последний MqlRates содержит устаревшие значения). Бары отрисовываются с запаздыванием на минуты и даже иногда десятки минут (а не 45 мс). Лечиться только перезапуском терминала. И если нагрузка большая то и после перегрузки тоже самое снова происходит
ES MINI дает легко сотни тиков в секунду в рабочую сессию (особенно в начале и конце).
Жесть, и явно не в тиках дело.
Так оно есть
Да спасибо за код. Это полезно когда мне не нужно считать текущий бар ( но в данном случае нужно)