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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

Нижняя строка: нет, поскольку накладные расходы на интерпретацию перегружают служебные данные диспетчеризации метода.

Ответ 4

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

Ответ 5

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

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

Не.

Ответ 6

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

OOP требует намного большего объема памяти (MALLOC) и намного больше операций для работы в памяти, чем процедурный код. Для выполнения своих задач требуется намного больше времени процессора. Это, по сути, "накладные расходы", завернутые в процедурный код, добавляя нагрузку на процессор для его выполнения, особенно при выполнении операций с базой данных.

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

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

Ответ 7

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

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