PHP: атрибуты vs аннотации: оптимизируем метадату Doctrine

<?php  #[ORM\Entity, ORM\Table(name: 'item_price')] class ItemPrice {     #[ORM\Id, ORM\Column(type: 'integer'), ORM\GeneratedValue]     private int $id;     #[         ORM\ManyToOne(targetEntity: Item::class, inversedBy: 'prices'),         ORM\JoinColumn(name: 'item_id', referencedColumnName: 'id')     ]     private Item $item;     #[ORM\Column(type: 'string')]     private string $amount;     #[ORM\Column(type: 'string')]     private string $currency; }

Одним из нововведений PHP 8.0 являются атрибуты. Атрибуты содержат метадату для классов, полей, функций; которая доступна через Reflection API. Казалось бы, то же самое, что и аннотации, тогда зачем обращать внимание на эту фичу?

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

Появляется необходимость парсинга в рантайме. Насколько это плохо? Рассмотрим, как это влияет на производительность на примере Doctrine.

Doctrine, как любая ORM, широко использует метадату для своей работы. В частности — маппинги бизнес-сущностей на таблицы в БД. Есть разные реализации способа хранения метадаты:

• Драйвер XML

• Драйвер YAML

• Статический PHP драйвер

• PHP драйвер

• Драйвер аннотаций

• Драйвер атрибутов

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

<?php  /**  * @ORM\Entity  * @ORM\Table(name="item_price")  */ class ItemPrice {     /**      * @ORM\Id      * @ORM\Column(type="integer")      * @ORM\GeneratedValue      */     private int $id;     /**      * @ORM\ManyToOne(targetEntity="Item", inversedBy="prices")      * @ORM\JoinColumn(name="item_id", referencedColumnName="id")      */     private Item $item;     /**      * @ORM\Column(type="string")      */     private string $amount;     /**      * @ORM\Column(type="string")      */     private string $currency; }

<?php  class ItemPrice {     public static function loadMetadata(ClassMetadata $metadata): void     {         $metadata->setPrimaryTable([             'table' => 'item_price',         ]);         $metadata->setIdGeneratorType(ClassMetadataInfo::GENERATOR_TYPE_AUTO);          $metadata->mapField([             'fieldName' => 'id',             'type' => 'integer',             'id' => true,         ]);         $metadata->mapManyToOne([             'fieldName' => 'item',             'joinColumns' => [                 [                     'name' => 'item_id',                     'referencedColumnName' => 'id',                 ],             ],             'inversedBy' => 'prices',             'targetEntity' => Item::class,         ]);         $metadata->mapField([             'fieldName' => 'amount',             'type' => 'string',         ]);         $metadata->mapField([             'fieldName' => 'currency',             'type' => 'string',         ]);     }      private int $id;     private Item $item;     private string $amount;     private string $currency; }

В качестве теста я 10 минут 1 активным пользователем выполнял запросы на получение метадаты всех классов. Использовалась связка Nginx + PHP-fpm с включенным opcache. Исходники доступны здесь.

Атрибуты показали неплохую производительность на уровне драйверов, использующих PHP-код. Разницу между AttributeDriver, StaticPHPDriver и PHPDriver, думаю, можно считать погрешностью. Главное, что можно увидеть по результатам тестирования — аннотации в 3 раза медленнее! Интересен так же тот факт, что кэширование не всегда может помочь ускорить приложение — в Doctrine метадата для каждого класса кэшируется отдельной записью. Это приводит к тому, что ее выгрузка и десериализация для каждого класса в отдельности выходит ненамного быстрее.

Если вы ищите способ оптимизировать ваше legacy приложение, и все запросы к БД уже давно проверены, возможно аннотации контроллеров и сущностей ORM — ваша следующая цель.

Тут можно столкнуться с проблемой: legacy — это когда куча кода, а теперь его нужно весь переписывать? Эту проблему можно решить с помощью еще одного варианта, который вы могли видеть в результатах бенчмарка — кодогенерации:

Этот вариант позволяет продолжать использовать аннотации, не переписывая весь проект, при этом получая бонусы производительности — ведь аннотации генерируются в код, а код попадает в opcache!

Резюмируя:

• Стоит ли использовать в новых приложениях атрибуты вместо аннотаций везде, где это представляется возможным? Однозначно да.

• Нужно ли переписывать аннотации в legacy проекте на атрибуты? Зависит от нефункциональных требований, возможно вам поможет кодогенерация. Например, подобный скрипт мы используем у себя на продакшене. (Еще рабочим вариантом может оказаться автоматический рефакторинг средствами rector)

Надеюсь, статья была полезна и познакомила вас с ещё одним преимуществом атрибутов перед аннотациями.