Блеск и нищета ООП - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Тут, как я понимаю, индекс определяется через бинарный поиск?
Нет, прямой доступ как в массиве.
__________
Эмм возможно погорячился, щас еще подумаю.
Вообще никто не мешает создать массив на всю величину типа и получать константный доступ. (switch работает только с интегральными типами)
В описанном вами случае удобнее ввести перечисление.
Нет, прямой доступ как в массиве.
__________
Эмм возможно погорячился, щас еще подумаю.
Вообще никто не мешает создать массив на всю величину типа и получать константный доступ. (switch работает только с интегральными типами)
В описанном вами случае удобнее ввести перечисление.
На всю величину типа? Да вы что! В данном случае на это потребуется 16 гб памяти (для массива типа int). Да и какой смысл на всю величину? Достаточно вычислить разницу между наибольшим и наименьшим значением. Но это всё-равно спорный вариант, т.к. при больших значениях нужно сначала согласовать с пользователем, сколько памяти он готов отдать программе. Поэтому это годится лишь при небольших значениях ключей (точнее при небольшой разнице между максимумом и минимумом). А так остаётся только бинарный поиск.
А так остаётся только бинарный поиск.
Нет, на самом деле не обязательно. Короче если надо отображение числа в енум, надо бинарный поиск, если достаточно работы с енумом и отображение енума в число, тогда константный.
Насчет памяти понимаю )) поэтому и написал что погорячился. это еще лонг не трогая.
всегда есть место вопросу - Зачем? сравните график спреда в онлайне и в тестере. В тестере ничего общего с реальностью...
Более подробное объяснение (доказательства) уже приводили где-то ?
Здесь принято доказательством свои заявления подкреплять, иначе даже смотреть на станут. ;)
Ребята, курите документацию по switch. Хороший switch - это коммутируемый переход, чья производительность не зависит от количества вариантов выбора. 1 вариант, 100 или 1000 - скорость его перехода будет постоянной.
всегда есть место вопросу - Зачем? сравните график спреда в онлайне и в тестере. В тестере ничего общего с реальностью...
Доказательства будут с другой стороны. Или опять только слова.
По большому счету интересует только факты.
Хотя я и так знаю что ООП работает медленнее, но предоставляет вполне конкретные удобства
Как и обещал выкладываю результаты профилирования одного проекта. (Уж не обессудьте, но некоторые функции замазаны, т.к. код не для широкой общественности).
Для начала скажу что это реальный ООП-проект, с сильным преобразованием исходных данных. Идея использования ООП в нем доведена до абсолюта. Например в нем вообще не используются глобальные переменные, массивы, функции вне классов - ведь они не достаточно ОО. Для его работы требуется история ордеров и сделок совершенных за весь период. Парсинг 6014 сделок и 6599 ордеров занимает всего 3.1 секунды или 0.25 милисекунды на одну транзакцию, оперативной памяти для развертывания всех сделок, ордеров и позиций требуется около 13 Мбайт, или в среднем 1 килобайт на транзакцию. - Я считаю что это очень неплохой результат для ООП-приложения:
Но посмотрим, на структуру затрачиваемого времени при инициализации приложения:
Видно, что большую часть времени занимает вызов функции AddNewDeal. Это композитная функция и реальная работа делегируется на RecalcValues (57%). Она же в свою очередь состоит из системных функций типа HistoryOrderGetInteger:
Обратите внимание, что время вызова этих функций примерно равномерно.
Замечу что это конец всего конвейера функций. Прежде чем дойти до этих расчетов необходимо пройти еще с десяток промежуточных ООП-методов, а ведь некоторые из них еще и виртуальные. Но время их выполнения ничтожно и в профилировщике они идут во второй половине списка.
Так как приложение 100% ООП мне очень легко отслеживать критические по времени выполнения участки кода и я могу очень эффективно находить новые пути для поднятия производительности. Уже сейчас я знаю, что оставшаяся часть (43%) на 80-90% состоит из вызовов CArray.Resize(). Есть несколько мест, где код не оптимизирован и переразметка массивов происходит чаще чем это необходимо. Я без труда смогу переписать эти ООП-модули и поднять производительность на 25%-30%. Без ООП это сделать было бы сложней, потому что каждая функция потенциально участвует в бесконечном количестве взаимосвзяей, и просчитать последствия изменений такой функции становится гораздо сложней.
В итоге получается, что даже сложный ООП-проект можно свести к пределу производительности базовых системных функций. А вот без ООП добиться подобной производительности будет сложней, потому что функций будет так много, что рано или поздно Вы допустите ошибку: понаделаете либо лишних вызовов, либо неоптимизированных двойников, либо слишком сложных и громоздких реализаций.
всегда есть место вопросу - Зачем? сравните график спреда в онлайне и в тестере. В тестере ничего общего с реальностью...
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Блеск и нищета ООП
tol64, 2014.07.07 09:12
Чтобы обратили внимание. Откройте новую тему и осветите свой вопрос более подробно. Покажите, как в реале и как в тестере. Предложите своё решение этой проблемы. Иначе всё так и останется "без шансов и без вариантов". )+++
to dimeon - Открывай тему, узнаешь множество аргументов почему это нельзя, и почему это надо.
Как и обещал выкладываю результаты профилирования одного проекта. (Уж не обессудьте, но некоторые функции замазаны, т.к. код не для широкой общественности).
...
К чему это всё? Вы не привели коды своих функций (если не считать какого-то вырванного фрагмента). Так что обсуждать? Здесь тема конкретно про сравнение производительности ООП и процедурного программирования. А то что ваши секретные функции якобы выполняют какую-работу, что-то куда-то делегируют, затрачивают какое-то время, а вы виртуозно управляетесь со всем этим - мы конечно безумно рады за вас, но какой толк от этой информации, если мы не видим кодов.
К чему это всё? Вы не привели коды своих функций (если не считать какого-то вырванного фрагмента). Так что обсуждать? Здесь тема конкретно про сравнение производительности ООП и процедурного программирования. А то что ваши секретные функции якобы выполняют какую-работу, что-то куда-то делегируют, затрачивают какое-то время, а вы виртуозно управляетесь со всем этим - мы конечно безумно рады за вас, но какой толк от этой информации, если мы не видим кодов.
Он показал что в реальных проектах никакого влияния direct call или virtual call не имеют.
на примере профилирования реального ООП-проекта покажу что его производительность в пределе стремится к производительности вызовов системных функций
Подавляющее большинство затрат приходится на вызов системных функций, где и проводят все почти время MQL программы. Расходы на организацию вызовов ничтожны по сравнению с полезной нагрузкой.