Каковы накладные расходы в PHP на мелких объектах?

Question

[Terion]

Пишу ORM. Хочется, чтоб под себя и, главное, чтобы была очень быстрая (в этом главный смысл — с нужным для меня функционалом и максимально оптимизированная).

И вот возник вопрос: при разборе объектов нужно выделять под свойства поля определенных типов, манипулировать ими, соответственно.


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


Пытался найти какую-то информацию на этот счет в сети — не нашел.

Answer 1

[EugeneOZ]

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

Comments

[egorinsk]

По моим наблюдениям, запросы к базе данных (если их не писал начинающий разработчик, не слышавший слова «индекс»), как раз занимают меньше времени, чем пережевыванием ORM'ом всяких хитрых абстракций. Тут никакое кеширование не поможет, язык менять надо — или отказываться от любых сложных конструкций.

[Terion]

egorinsk, вот поэтому я и пишу свою orm, проще и быстрее, потому что тормознутость систем вроде доктрины просто убивает.

EugeneOZ, спасибо, к этому и склоняюсь) просто сомнения были

[egorinsk]

Terion, так самое печальное, что когда вы захотите применить нормальный ООП-подход, ввести типы данных-валидаторы-мапперы-отношения-адаптеры БД-модельки-репозитории-Query Builders-метаданные, у вас скорее всего, выйдет тоже что-то монструозное. А поскольку PHP имеет привычку перезапускаться на каждом запросе, вам придется возиться со всякими кешами метаданных (например, чтобы не парсить XML-конфиг на каждом запросе), в общем, устанете.

[Terion]

egorinsk, типы данных, валидаторы, мапперы, отношения и ООП — вот этим я как раз сейчас и занимаюсь. И пока получается очень даже шустро и компактно (правда, переписываю уже третий раз, меняя интерфейс, но то такое). Адаптер и квери билдеры уже есть — я это делаю для Codeigniter, поверх ActiveRecord и DB Forge, которые там тоже очень неплохо реализованы и никаких нарекений по производительности пока не вызывали.
XML-конфигов у меня нет. Всё пляшет от объектов и их свойств. А результаты обработок свойств лёгенько кешируются в APC.
Конечно, вряд ли это будет супер-пупер универсально и на все случаи жизни, но 98% юзкейсов покрывать должно)

[EugeneOZ]

egorinsk, Вы пишете полную чушь.

[Gero]

Соглашусь с EugeneOZ. egorinsk не компетентен и явно не имеет опыта в данном вопросе.

Answer 2

[egorinsk]

Во-первых, точный ответ дадут только тесты. Набросайте по-быстрому подобие того, что вы хотите сделать, и проверьте, сколько времени уйдет, например, на создание 100 000 объектов.

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

Я бы предпочел обойтись без этого. Мне кажется, вы усложняете себе жизнь.

Вообще, сложные объектные конструкции лучше реализовывать на языках выроде .NET/Java, а не на скриптовых — там все это будет работать гораздо быстрее.

Answer 3

[Алексей Сундуков]

В PHP нет больших или маленьких объектов по определению. В силу нетипизированности языка. А накладные расходы по памяти можно прикинуть посмотрев устройство zend структур.

На вскидку на хабре нашел перевод про массивы: "Насколько большие массивы (и значения) в PHP?", но точно были и другие статьи в которых очень неплохо описан принцип организации памяти под PHP типы.

Answer 4

[Владимир Чернышев]

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

Удобнее, имхо, просто приводить SQL-типы в PHP-типы и обратно непосредственно при чтении/записи, если вы только в своём приложении не используете ООП обёртки для всех скалярных типов в PHP, типа if ($user->login.equal(new String($_POT['login']))