Поток событий. Как контролировать и сделать событие idle ? (+ решено) - страница 3

Новый комментарий
 

Yedelkin:

Аналогично, если в очереди mql5-программы уже находится событие ChartEvent или такое событие обрабатывается, то новое событие такого типа не ставится в очередь".

Хм. это реально плохо. Это теоретически означает, что если скажем индюк и советник пользуются событиями независимо, то могут быть пропуски и там и там.

Тогда теряется смысл в использовании события как надежный способ передачи данных.

Пичаль.

 
sergeev:

Ваш вопрос "с какой примерно частотой следует отправлять пользовательские события, чтобы они не переполняли очередь"

мой ответ на первой странице - "с частотой вызова OnChartEvent".

То есть одно событие - один OnChartEvent.  Не должно быть более двух событий в промежутке.

Вот и вся математика.

еще раз - читайте первую страницу. Я показал как избежать накапливания пользовательских событий, когда вместо пользовательского обрабатывается терминальное. Все просто.

Ещё раз, вежливо :) Вы решали свою проблему, я пытаюсь решить свою, другого плана. Когда читал обсуждение, ответа на свои вопросы не нашёл. На мой же основной вопрос (про потребление оперативной памяти) Вы так и не ответили (если уж взялись отвечать). 

Поясняю. Передо мной не стоит задача "сделать обновление некой функции, но быстрее чем предлагает MQL по таймеру". Тем более, таким замудренным способом, который в итоге предложен. У меня пользовательские события с нескольких графиков с потиковой частотой бомбардируют отдельный график, на котором расположены эксперт и функция-обработчик пользовательских событий. Соответственно, результат решения Вашей узконаправленной задачи (EventChartCustom внутри OnChartEvent) совершенно не вяжется с моей схемой работы с пользовательскими событиями.

 

Yedelkin:

Поясняю. Передо мной не стоит задача "сделать обновление некой функции, но быстрее чем предлагает MQL по таймеру". Тем более, таким замудренным способом, который в итоге предложен. У меня пользовательские события с нескольких графиков с потиковой частотой бомбардируют отдельный график, на котором расположены эксперт и функция-обработчик пользовательских событий. Соответственно, результат решения Вашей узконаправленной задачи (EventChartCustom внутри OnChartEvent) совершенно не вяжется с моей схемой работы с пользовательскими событиями.

он не замудренный, а простой. Если вы не в состоянии его понять, то это не мой головняк. это раз

он не внутри OnChartEvent, а раскидан по всему коду. Вы сами придумываете себе узкие ограничения на его работу. это два.

Аналогично, если в очереди mql5-программы уже находится событие ChartEvent или такое событие обрабатывается, то новое событие такого типа не ставится в очередь.

это неверно или баг или ошибка документации или недосказанность условий.

События успешно все встают в очередь и никакие не отбрасываются. Иначе бы не появилась данная моя тема.

я пытаюсь решить свою, другого плана
как влияет переполнение очереди событий на размер оперативной памяти? Если очередь событий оказалась переполненной, то куда деваются события, переполнившие очередь?

Renat и Rosh уже ответили на этот вопрос?
 
Rosh:

Если событие отбрасывается, значит оно просто не ставится в очередь. Память не растет.

Фуф! Вот главное, что хотел понять. А поскольку TheXpert сказал, что на саму очередь тратится всего несколько Мб, то, скорее всего, утечка памяти происходит в другом месте... Будем исходить из этого утверждения, пока не доказано обратное.

Rosh:

Если возникают такие проблемы, то всё очень плохо. Думаю, переаолненная очередь событий - это последнее место, где нужно искать проблемы с памятью.

 Да пытаюсь искать везде, где только можно.

Но обратим внимание, что из трёх дисквалифицированных экспертов как минимум два эксперта работали с потоком пользовательских событий  (автор третьего не отвечает на запрос). У Lizar'а (работает с пользовательскими событиями) тоже повышенное потребление оперативной памяти. А у tol64  крайне малое потребление памяти связано с тем, что пользовательские события используются реже, чем раз в минуту, если я всё правильно понял. Вот и получается, что волей-неволей приходится сомневаться и в эффективности реализации концепции пользовательских событий. Пока не получишь исчерпывающий ответ.

 
Yedelkin:

Но обратим внимание, что из трёх дисквалифицированных экспертов как минимум два эксперта работали с потоком пользовательских событий  (автор третьего не отвечает на запрос). У Lizar'а (работает с пользовательскими событиями) тоже повышенное потребление оперативной памяти. А у tol64  крайне малое потребление памяти связано с тем, что пользовательские события используются реже, чем раз в минуту, если я всё правильно понял. Вот и получается, что волей-неволей приходится сомневаться и в эффективности реализации концепции пользовательских событий. Пока не получишь исчерпывающий ответ.

При этом не забудем тот факт, что события эксперт получал от индикаторов, которые были запущены на множестве инструменто и таймфреймов, в общей сложности около 80-ти, если правильно помню. Каждый индикатор потрбляет ресурсы под индикаторные буфера, вот в этом и зарыта собака.
 
sergeev:

он не замудренный, а простой. Если вы не в состоянии его понять, то это не мой головняк. это раз

Как понял, так и написал, что замудрённый. Иначе бы и н касался.

sergeev:

он не внутри OnChartEvent, а раскидан по всему коду. Вы сами придумываете себе узкие ограничения на его работу. это два. 

Да-да, EventChartCustom не внутри OnChartEvent, а, типа, снаружи. Теперь смотрим Ваш же код:

void OnChartEvent(int iview, int id, long lparam, double dparam, string sparam)
{
    if (id==CHARTEVENT_CUSTOM+VM_IDLE)
    {
      ... 
    }
    EventChartCustom(m_chart, VM_IDLE, (long)event_idle, 0, ""); // отправили событие с указанием последнего счетчика
}

Очевидно, что в данном коде EventChartCustom не внутри OnChartEvent, и я очень ошибся :)

 
sergeev:

это неверно или баг или ошибка документации или недосказанность условий.

События успешно все встают в очередь и никакие не отбрасываются. Иначе бы не появилась данная моя тема.

 Есть как минимум ещё одна версия: в Вашей конкретном случае очередь попросту не переполняется (в силу эффективности кода), вот и нет фактов отбрасывания событий.

 
Yedelkin:
 

 Есть как минимум ещё одна версия: в Вашей конкретном случае очередь попросту не переполняется (в силу эффективности кода), вот и нет фактов отбрасывания событий.

вот мой конкретный случай, с которого начал демонстрацию  неотбрасывания идентичных событий

https://www.mql5.com/ru/forum/5091#comment_112780

там же написал почему возникает переполнение.

Да-да, EventChartCustom не внутри OnChartEvent, а, типа, снаружи. Теперь смотрим Ваш же код:

Зри в корень! Я показал демонстрацию проблемы и её решения.   Этот вызов EventChart может быть где угодно в коде.

 
Rosh:
При этом не забудем тот факт, что события эксперт получал от индикаторов, которые были запущены на множестве инструменто и таймфреймов, в общей сложности около 80-ти, если правильно помню. Каждый индикатор потрбляет ресурсы под индикаторные буфера, вот в этом и зарыта собака.
Это Вы про японца? Ну, в моём случае всё проще: один универсальный индикатор с 8-ю или 15-ью расчётными индикаторными буферами, запущен на 6 инструментах на одном таймфрейме. Т.е. всего 6 индикаторов. И что, теоретически такая схема может за неделю сожрать 2Гб?
 
Yedelkin:
Это Вы про японца? Ну, в моём случае всё проще: один универсальный индикатор с 8-ю или 15-ью расчётными индикаторными буферами, запущен на 6 инструментах на одном таймфрейме. Т.е. всего 6 индикаторов. И что, теоретически такая схема может за неделю сожрать 2Гб?
Почитайте статью Уменьшаем расход памяти на вспомогательные индикаторы, может быть полезной.
 
Rosh:
Почитайте статью Уменьшаем расход памяти на вспомогательные индикаторы, может быть полезной.

Спасибо, у меня и так всё уже заоптимизировано там :) В том числе и с учётом данной статьи, насколько помню. Придётся ждать следующей степени просветления :)

А вот можно ли как-то определить, сколько потребляет отдельно эксперт,  и отдельно индикатор, если они работают в связке через пользовательские события?

1234567
Новый комментарий
Причина обращения: