Сравнение скорости - Процедурные и ОО в устных переводах

Question

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

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

Итог: насколько велика (если таковая имеется) производительность в действительности, если использовать OO против Procedural на интерпретируемом языке?

Answer 1

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

Не.

:)

Answer 6

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

Answer 7

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

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