Неужели Лось так медленно?

Недавно я загрузил Муса. Экспериментально я переписал существующий модуль в Музе. Кажется, это удобный способ избежать написания много повторяющегося кода. Я проверил тесты модуля, и я заметил, что это было немного задержано. Я профилировал код с -d: DProf, и кажется, что только включая строку

no Moose;

в коде увеличивается время работы примерно на 0,25 секунды (на моем компьютере). Это типично? Я делаю что-то неправильно, я его неправильно установил или должен ли мы действительно ожидать эту задержку?

Ответ 1

Да, есть немного штрафа за использование Муса. Однако это только штраф за запуск, а не во время выполнения; если вы написали все правильно, то во время выполнения все будет довольно быстро.

Вы также указали эту строку:

__PACKAGE__->meta->make_immutable;

во всех ваших классах, когда вы no Moose;? Вызов этого метода сделает его (время выполнения) быстрее (за счет времени запуска). В частности, построение и разрушение объектов эффективно "встроены" в ваш класс и больше не вызывают мета-API. Настоятельно рекомендуется сделать ваши классы неизменными. Это делает ваш код намного быстрее, с небольшими затратами времени компиляции. Это будет особенно заметно при создании многих объектов. 1 2

Однако иногда эта стоимость по-прежнему слишком велика. Если вы используете Moose внутри script или каким-либо другим способом, когда время компиляции составляет значительную часть вашего общего времени использования, попробуйте сделать s/Moose/Moo/g - если вы не используете модули MooseX, вы можете, вероятно, переключитесь на Moo, цель которого - быть быстрее (при запуске), сохраняя при этом 90% гибкости Moose.

Поскольку вы работаете с веб-приложением, рассмотрели ли вы использование Plack/PSGI?

1Из документов make_immutable, в Moose:: Cookbook:: Основы:: Recipe7суб >
2 См. также статью Стевана Маленькая статья: Почему make_immutable рекомендуется для классов Mooseсуб >

Ответ 2

См. Moose:: Cookbook:: Часто задаваемые вопросы:

Я слышал, что Лось медленно, это правда?

Опять же, это сложно, поэтому Да и Нет.

Во-первых, ничто в жизни не является бесплатным, и некоторые функции Муха стоят дороже, чем другие. Это также политика Moose, чтобы взимать с вас только за те функции, которые вы используете, и сделать все возможное, чтобы не налагать дополнительных нагрузок на выполнение вашего кода на функции, которые вы не используете. Конечно, использование Moose действительно связано с некоторыми накладными расходами, но в основном это время компиляции. На этом этапе у нас есть несколько вариантов для получения необходимой скорости.

В настоящее время мы предоставляем возможность сделать ваши классы неизменными как средство повышения скорости. Это будет означать немного большую стоимость времени компиляции, но увеличение скорости выполнения (особенно при построении объекта) довольно значимо. Это можно сделать с помощью следующего кода:

MyClass->meta->make_immutable();

Мы регулярно конвертируем горячие точки класса:: MOP в XS. Флориан Рагвиц и Юваль Когман в настоящее время работают над тем, чтобы скомпилировать ваши аксессоры и экземпляры непосредственно на C, чтобы каждый мог наслаждаться быстрым быстрым OO.

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

Использование Moose и Dancer для этого проекта имело дополнительное преимущество: моя небольшая демонстрационная заявка сократилась примерно с 5000 строк до менее 1000 строк.

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

Ответ 3

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