Библиотеки: TesterBenchmark - страница 3

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

Василий, вы серьезно говорите о соизмеримости скорости выполнения OrderSend в тестере и в реале?

В онлайне она самая медленная, потому что отправляет информацию на сервер и ждет ответа, а в тестере (если не включать задержку, но о ней речи не шло), то отправка и ожидание происходят моментально.

Задача этой библиотеки - как раз скорость тестера и измерить (с точки зрения торговых функций).

Да, не подумал. Мой косяк. Конкретно OrderSend работает в тестере гораздо на порядок быстрее. Но, говорю по-прежнему, что львиная доля времени при тестировании съедается именно системные функциями. И в МТ5 очень хорошо съедается, т.к. там, в отличии от МТ4, идет полная имитация торгового окружения. Поэтому даже если обвязку ускорить на 16%, то это будет 16% от 5% общего времени занимаемого этой самой обвязкой. Т.е. любые идеи оптимизации кода в МТ5 очень благородные, но бессмысленные, т.к. в лучшем случае мы улучшим показатель на эти 5%.

 
Vasiliy Sokolov:

Да, не подумал. Мой косяк. Конкретно OrderSend работает в тестере гораздо на порядок быстрее. Но, говорю по-прежнему, что львиная доля времени при тестировании съедается именно системные функциями. И в МТ5 очень хорошо съедается, т.к. там, в отличии от МТ4, идет полная имитация торгового окружения. Поэтому даже если обвязку ускорить на 16%, то это будет 16% от 5% общего времени занимаемого этой самой обвязкой. Т.е. любые идеи оптимизации кода в МТ5 очень благородные, но бессмысленные, т.к. в лучшем случае мы улучшим показатель на эти 5%.

Не согласен с последним утверждением.

Благодаря исследованиям fxsaber, в МТ5 уже на порядки ускорена работа с историей сделок.

 
Andrey Khatimlianskii:

Не согласен с последним утверждением.

Благодаря исследованиям fxsaber, в МТ5 уже на порядки ускорена работа с историей сделок.

Я не спорю. Fxsaber вносит большой вклад в развитие языка и сообщества в целом. Он делает нужные вещи. В МТ5 много косяков и здорово что их кто-то находит. Но не стоит путать грубые ошибки в работе МТ5, в результате которых скорость работы снижается на порядки и ловлю блох в коде СБ. Где-то безусловно ускорить либу можно и даже нужно. Но если в ней нет грубых ошибок, ни каких ускорений на порядки там не будет.

 
Vasiliy Sokolov:

Я не спорю. Fxsaber вносит большой вклад в развитие языка и сообщества в целом. Он делает нужные вещи. В МТ5 много косяков и здорово что их кто-то находит. Но не стоит путать грубые ошибки в работе МТ5, в результате которых скорость работы снижается на порядки и ловлю блох в коде СБ. Где-то безусловно ускорить либу можно и даже нужно. Но если в ней нет грубых ошибок, ни каких ускорений на порядки там не будет.

Про СБ даже не думал.

Мне кажется, она просто под руку попалась для сравнения.

 
Andrey Khatimlianskii:

Не согласен с последним утверждением.

Благодаря исследованиям fxsaber, в МТ5 уже на порядки ускорена работа с историей сделок.

История сделок кстати, косячила еще в 2013 году. Помню я тогда заметил что следующий код работает не линейно:

int total = HistoryDealsTotal();
for(int i = 0; i < total; i++)
{
   ulong ticket = HistoryDealTicket(i);
   HistoryDealSelect(ticket);
}

Т.е. чем больше i, тем медленней работает HistoryDealSelect. При том замедление было экспоненциальное. Так пришлось график в ексель этого замедления рисовать и плотно со сервисдеском общаться. Так что да, косяки были есть и будут.

 

Сейчас код немного подправил, изменив OrderSend на OrderSendAsynch. Результаты стали ожидаемо другими:

85% времени занимает HistorySelect. Т.е. опять упираемся в системные вызовы, но чуточку другие.

 
Библиотека писалась для этого
При написании разных версий кода может возникнуть необходимость измерения влияния их на общую производительность советника в тестере. Это позволяет не только понять, насколько оптимален написанный код по сравнению с другим, но и дает предпосылки к будущей быстрой оптимизации советника. Такой подход позволяет выявить "бутылочное горлышко" в производительности советника.

И такой подход сработал не только с MT4Orders.mqh, но и с Trade.mqh - стал заметно быстрее после СД. Так же результаты использования библиотеки позволили заметно ускорить некоторые другие моменты (в частности).

Звучали рациональные решения и т.д.

Факт - время на Оптимизацию очень сильно зависит от того, как написан код. Библиотекой хотел удобно обратить не только свое, но и внимание других на это.

Как пример (да простит меня Автор), в кодобазе есть много советников, которые, с точки зрения производительности, в Оптимизаторе не блещут хотя бы из-за используемой торговой библиотеки. На самом деле это даже некоторый бич кодобазы (и, уверен, Маркета), когда умный и сильный ООП-советник сводит на нет все скоростные возможности MT5-тестера.

Для тестера, похоже, почти ничего не пишется. А это огромная составляющая работы с ТС.

 
fxsaber:

... когда умный и сильный ООП-советник сводит на нет все скоростные возможности MT5-тестера.

Еще раз взгляните на профилирование Вашего примера. Все упирается в адски медленную HistorySelect(0, TimeCurrent). В ООП можно обойти вызов HistorySelect, чем существенно сократить время выполнения программы по сравнению с вызовом чистых MQL5 функций. Утверждение что ООП сводит на нет все скоростные возможности МТ5 некорректно. В некоторых случаях благодаря ему можно наоборот ускориться, как в случае с HistorySelect.

 
Vasiliy Sokolov:

Еще раз взгляните на профилирование Вашего примера. Все упирается в адски медленную HistorySelect(0, TimeCurrent). В ООП можно обойти вызов HistorySelect, чем существенно сократить время выполнения программы по сравнению с вызовом чистых MQL5 функций. Утверждение что ООП сводит на нет все скоростные возможности МТ5 некорректно. В некоторых случаях благодаря ему можно наоборот ускориться, как в случае с HistorySelect.

По какой-то причине Вы не видите, что HistorySelect вызывается только в случае, когда нет открытых позиций. Более того, сразу после этого открывается новая позиция. Т.е. обращение к истории идет крайне редко. Есть факт (проверьте хотя бы по времени в логах), что время в Тестере отличается, в зависимости от реализации.


Все пишу через ООП и даже не намекал на возможную его тормознутость. Подавляющее большинство Авторов особенно увлеченных ООП создают порой ОЧЕНЬ удобные и красивые конструкции. Однако, не уделяются свое внимание на производительность своих решений. А это очень важно для тестера. Оптимизировать свой советник на многие часы быстрее (или дешевле в Облаке) хочет каждый. Часто бывает, что какой-нибудь давно написанный и автоматом подключаемый ООП-модуль содержит бутылочное  горлышко. Но его, конечно, никто не замечает.


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

 
fxsaber:

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

В CStrategy торговые операции осуществляются через CTrade напрямую. Т.е. в CStrategy нет вообще никакой своей торговой логики. В тестовом эксперте я не увидел иной торговой логики, чем открытие/закрытие позиции через N секунд. Исторических позиций CStrategy также не хранит, поэтому данный пример в CStrategy не реализуем к сожалению.

fxsaber:

Подавляющее большинство Авторов особенно увлеченных ООП создают порой ОЧЕНЬ удобные и красивые конструкции. 

Подавляющего большинства Авторов увлеченных ООП нет в принципе, к сожалению. Авторов ООП может всего 5-10 человек на весь ресурс, включая авторов СБ из MetaQuotes. Нас мало и мы в тельняшках:)

fxsaber:

Все пишу через ООП и даже не намекал на возможную его тормознутость. Подавляющее большинство Авторов особенно увлеченных ООП создают порой ОЧЕНЬ удобные и красивые конструкции. Однако, не уделяются свое внимание на производительность своих решений. А это очень важно для тестера. Оптимизировать свой советник на многие часы быстрее (или дешевле в Облаке) хочет каждый. Часто бывает, что какой-нибудь давно написанный и автоматом подключаемый ООП-модуль содержит бутылочное  горлышко. Но его, конечно, никто не замечает.

То что ООП код выполняется медленней процедурного кода, лично мне ни о чем не говорит. Давайте посуществу: какие методы CTrade являются бутылочным горлышком? Почему? Что говорит профилирование этих методов? Как в тестере Вы определяете медленные участки кода? 

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