Сравнение скорости - процедурные и объектно-ориентированные в интерпретируемых языках

В интерпретируемых языках программирования, таких как PHP и JavaScript, каковы последствия перехода от объектно-ориентированного подхода к процедурному подходу?

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

Итог: насколько велико (если есть) действительно поражение производительности при использовании объектно-ориентированного программирования или процедурного интерфейса на интерпретируемом языке?

Ответов (7)

Решение

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

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

Если вы используете интерпретируемый язык, разница не имеет значения. Вы не должны использовать интерпретируемый язык, если производительность является проблемой. Оба будут работать примерно одинаково.

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

ООП требует гораздо большего выделения памяти (MALLOC) и гораздо большего числа операций для выполнения в памяти, чем процедурный код. Для выполнения своих задач требуется гораздо больше процессорного времени. По сути, это «накладные расходы», связанные с процедурным кодом, увеличивающие нагрузку на ЦП при его выполнении, особенно при выполнении операций с базой данных.

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

Если вы не ожидаете, что ваш сайт будет очень загружен, обязательно используйте ООП. Если вы создаете систему с высоким трафиком, вам нужно исключить каждый цикл ЦП из обработки и каждый байт из вывода, который вы можете.

Итог: нет, потому что накладные расходы на интерпретацию превышают накладные расходы на отправку методов.

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

Так что на самом деле это не имеет значения (по крайней мере, по моему опыту).

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

Просто запомните первое правило оптимизации.

Не надо.

:)

К сожалению, я тоже сделал свои тесты. Я тестировал скорость, и она примерно такая же, но при тестировании использования памяти, получая memory_get_usage () в PHP, я увидел значительно большее число на стороне ООП.

116 576 байт для ООП до 18 856 байт для процедурных. Я знаю, что «железо дешевое», но давай! Увеличение использования на 1000%? Извините, это не оптимально. И если так много пользователей одновременно заходят на ваш сайт, я уверен, что ваша оперативная память просто сгорит или закончится. Я ошибся?