Блеск и нищета ООП - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Он показал что в реальных проектах никакого влияния direct call или virtual call не имеют.
Подавляющее большинство затрат приходится на вызов системных функций, где и проводят все почти время MQL программы. Расходы на организацию вызовов ничтожны по сравнению с полезной нагрузкой.
Да где он показал-то? Таблица с какими-то именами функций и замерами - разве это аргумент? Мы тут не телепаты вообще-то. Нужно видеть код функций, тогда ещё можно о чём-то говорить.
Да где он показал-то? Таблица с какими-то именами функций и замерами - разве это аргумент? Мы тут не телепаты вообще-то. Нужно видеть код функций, тогда ещё можно о чём-то говорить.
Он показал что в реальных проектах никакого влияния direct call или virtual call не имеют.
Подавляющее большинство затрат приходится на вызов системных функций, где и проводят все почти время MQL программы. Расходы на организацию вызовов ничтожны по сравнению с полезной нагрузкой.
+100 Да, именно так!
Более того, мной было замечено, что когда приходилось переписывать разросшиеся классы, таким образом, что бы часть их функций выполняли другие классы (включение/декомпозиция), общая производительность увеличивалась, а контроль над кодом возрастал. Т.е. на практике наблюдается обратная ситуация той, что нам пытается доказать Integer и любители олдскул Cи: количество классов растет, количество методов растет а производительность, наоборот, увеличивается.
Да где он показал-то? Таблица с какими-то именами функций и замерами - разве это аргумент? Мы тут не телепаты вообще-то. Нужно видеть код функций, тогда ещё можно о чём-то говорить.
+100 Да, именно так!
Более того, мной было замечено, что когда приходилось переписывать разросшиеся классы, таким образом, что бы часть их функций выполняли другие классы (включение/декомпозиция), общая производительность увеличивалась, а контроль над кодом возрастал. Т.е. на практике наблюдается обратная ситуация той, что нам пытается доказать Integer и любители олдскул Cи: количество классов растет, количество методов растет а производительность, наоборот, увеличивается.
Новый способ самовнушения? Давайте, давайте.
Василий, вы бы, все-таки, почитали, что я пытался здесь доказать (и что бы вы об не думали, доказал).
Замечу однако, что наличие исходников Вам ничего не даст. Совокупная сложность не та. Даже проанализировав исходники вы бы сказали: "ну что-то там вызывается, что-то считается, откуда-то что то берется, но что именно не понятно, поэтому снова ничего не доказано."
Вообще пожалуй да, вы правы, отдельно взятые функции наверно мало о чём скажут. Какой смысл тогда вообще было заводить разговор о вашей проге, если для всех остальных это кот в мешке.
По сути главное что нас интересует - это общее количество переходов по виртуальным методам, и общее время затраченное на это. Вот в вашей таблице есть какая-то закрашенная функция, выполняемая 5 млн. раз. Не знаю что она из себя представляет, может там как-раз виртуальный метод с простейшим действием. Впрочем 5 млн. - это мелочь. Полагаю, что у вас нет тяжёлых расчётов в программе, поэтому и обсуждать как бы нечего. Вот если бы допустим вычислялась система линейных уравнений 30000x30000, а доступ к элементам матрицы осуществлялся через виртуальные методы, то здесь уже есть о чём говорить.
Новый способ самовнушения? Давайте, давайте.
Василий, вы бы, все-таки, почитали, что я пытался здесь доказать (и что бы вы об не думали, доказал).
Дмитрий, я ни за тебя и ни против. Чтоб разобраться нужно знать подноготную инлайнинга компилятором, но открыть эту инфу для MQ равносильно помощи в написании декомпилера.
Такой инфой тут (из обсуждающих) обладает лишь Ренат, так что нам придётся положиться на его слово. Другого пути не вижу.
Если он говорит что ты некорректно ставишь тест, видимо так и есть.
Вопрос в другом, корректно в таком случае может поставить тест лишь MQ, вот этого и нужно добиваться.
Как говориться тест на тест, моё слово против твоего. А ты пытаешься доказать недоказуемое. Не возможно ни доказать ни опровергнуть твои утверждения не имея с чем сравнивать.
Декомпилер тут не в кассу.
Просто надо понимать и знать техники оптимизирующих компиляторов, чтобы не тестировать упрощенные вырожденные случаи, которые зверски оптимизируются и вырождаются в линейный код. Зря чтоли мы четвертое поколение компиляторов выпустили.
Речь именно об этом.
Вот если бы допустим вычислялась система линейных уравнений 30000x30000, а доступ к элементам матрицы осуществлялся через виртуальные методы, то здесь уже есть о чём говорить.
В таких случаях первый же рефакторинг дал бы прирост ускорения в сотню раз. Причем виртуальный вызов был бы на десятом месте по затратам.
То есть, пример нереальный.
Давайте тогда все на ассемблере писать. По-любому будет быстрей.
Не понимаю суть проблемы. НИ разу не видел советника или индикатора с 1 мБ кода.
Сам вызов любой функции тоже занимает определенное время . Давайте и от функций откажемся!
Контроль над большими проектами намного удобней с ООП.
Кроме того, скорость исполнения кода очень часто не так критична как время пинга до брокера и ответ брокра по приказу.
Посмотрите алгоритмы HFT. Они требуют максимального быстродействия, но каких то сложных вычислений вы там не найдете.
PS. Что добраться из пукта А в Пункт Б как правило не нужен суперкар или карьерный БЕЛАЗ. Достаточно мопеда!