Помогите с ООП - страница 8
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Некорректное сравнение, т.к. не учитывается время на автоматическое удаление объектов.
Изменил.
Откуда берутся 123 мегабайта после V3 - не знаю.
Вопрос, сколько раз в Вашем бенчмарке прогоняется каждая функция?
Нужен вывод среднего времени, количества прогонов и stddev.Вопрос, сколько раз в Вашем бенчмарке прогоняется каждая функция?
Ровно один раз.
В боевом советнике интересуют всплески лагов. Теоретическими экспериментами не сильно занимался, поэтому подобную штуку не делал.
Vasiliy Sokolov #:
Нет, корректное. И это принципиальный момент. Автоматическое удаление происходит не в основном потоке, где стоимость времени крайне дорогое.
К сожалению, если замерить внутри функции и снаружи, то время разное. Внутри - быстрее. Т.е. удаление объектов как-то влияет. Поэтому про другой поток версия немного сомнительна.
Второй момент. Обратите внимание на V2. Там нет удаления объектов и целенаправленно допущена прямая утечка памяти. Даже в этом случае выделение объектов идет 1.4 сек. против 1.2 в V1, хотя время на удаление не тратится вообще.
У меня картина обратная.
Во время выполнения mql программы никакой сборщик ничего не удаляет, ни в том же потоке, ни в другом.
Сборщик номинально присутствует, но он выполняется только по завершению работы модуля. Сообщения про leaked memory в журнале - это как раз сборщик.
Ровно один раз.
В таком случае бенчмарк нерелевантен. По крайней мере не для меня.
Дело не в моей реализации. Замерить можете по-старинке.
Поэтому про другой поток версия немного сомнительна.