Потребление памяти и длина имени переменной в PHP
21 января 2013
Недавно всплыло обсуждение именования переменных в Yii, а именно
class CComponent { private $_e; private $_m;
Я согласен, что выглядит плохо, но именно в данном случае такие имена переменных более-менее оправданы и в Yii2 останутся примерно такими же:
class Component extends \yii\base\Object { /** * @var Vector[] the attached event handlers (event name => handlers) */ private $_e; /** * @var Behavior[] the attached behaviors (behavior name => behavior) */ private $_b;
Дело в том, что каждый экземпляр класса с нормальными именами переменных будет кушать больше памяти. Например, $_behaviors
и $_events
скушают 8 байт на экземпляр.
Конечно, 8 байт ничто и сокращать таким образом переменные в обычных приложениях определённо не стоит. Но не в случае самого-самого базового класса фреймворка. В зависимости от приложения, наследников Component
может быть довольно много. Например, на 1000 объектах AR накладной расход выльется в 8 килобайт.
Комментарии RSS по email OK
какая трагедия!
такие имена - уродство.
Eugene OZ солидарен
Смешная оптимизация. В конце-концов можно подменять имена при сборке yiilite для страждущих.
Тоже несогласен.
По теме очень и очень хорошая статья: habrahabr.ru/post/166341/
На реальном тесте выигрыша никакого: gist.github.com/4583515
По поводу длины названия переменной: gist.github.com/4583631
А меня вот именно эти переменные во фреймворке никогда не напрягали. Крутые имена нужны для поддержки приложений с которыми ты не знаком. А в случае Yii - ты все равно там чуть ли не наизусть весь код знаешь. "Поэтому что же такое $_e" у меня по моему ни разу не возникал.
Ну это смешно, чесслово. При 10Мб занятой памяти экономить 8кб и получать нечетабельный код? Пфф.
На сегодняшний день проблем с памятью нет вообще. Стоит она копейки и на быстродействие скрипта влияет минимальным образом. Та же магия дает куда больший оверхед.
Другое дело, что для приватных свойств по большому счету неважно, как они будут называться.
Странно, что еще даже тестового релиза нет, а уже какая-то сомнительная оптимизация идет. Не тем путем идет развитие, как мне кажется.
Эм.. это же приватные имена свойств класса ядра, не все ли равно? Мы сталкиваемся с ними только когда колупаемся в ядре.
Честно - facepalm, такого рода оптимизация выливается в затуп программиста, который будет читать этот код. Если же вынуждать не лазить внутрь фреймворка разработчиков, то таким образом вы тормознёте его развитие.
И ещё, почему не по PSR?
resurtm,
Ну почему никакого?
Eugene OZ, lemb, senz, Anton Shevchuk,
Это не часть API, а
private
. Документация будет достаточно хорошей, чтобы лезть читать код вообще не пришлось.ostin, это было в 1.1. В 2.0 перекочевало без изменений.
Anton Shevchuk, все PSR после PSR-0, который действительно хорош, субъективные. Взяли часть Symfony 2 и назвали стандартом.
Sam, запустил у себя:
Sam, вариант с выключенным XDebug (а вдруг!):
На именах экономите, а на нижнем подчёркивании - нет. PSR 0, 1, 2 стоило бы поддерживать, а то после других либ yii вызывает неприятные ощущения своим стилем кодирования и читается тяжело.
Тоже считаю, что единственный нормальный PSR - нулевой. Все остальные нигде не поддерживаю.
Брр...
Мой сервак с 32 гигами будет просто счастлив, что скрипты жрущие 3-3.5 мб памяти, будут жрать на 10 кб меньше
AmdY, стиль будет очень близок к PSR-1 и PSR-2 с небольшими расхождениями. Такого как в Yii 1.1 не будет. Я сам с него фигел долго :)
Dr.Death, такие мелочи в общей куче очень сильно влияют, хоть по отдельности и кажутся незначительными. Естественно, заниматься оптимизацией для Yii2 мы будем уже после альфы. Эта штука просто перекочевала как есть из 1.1.
Лучше извечную проблему с размножением объектов child->parent решите, чтоб памяти жрало меньше :D
Тема крайне холиварная и напоминает старый демотиватор demotivators.to/media/posters/853/67347488_sut-obschestvennogo-mneniya.jpg
сделал короткие название - все обсирают, фу как некрасиво, нечитаемо сделал длинные - фу фигня, на пустом месте жрет 10кб
Не правда, все давно знают, что читабельность кода важнее и 1000кб.
По поводу стиля Yii - именно он меня испугал в свое время и я так и не стал использовать Yii. Отнесся как несерьезному проекту. PSR, конечно, лучше всего, но хотябы общеупотребимые PEAR или Zend сделать.
мне кажется, что стиль кода yii нравится только одному Qiang
в любом случае, он не иероглифами написан, вполне читается
соглашусь, что читаемость важнее, но с другой стороны - две приватных переменных в классе, раздули обсуждение
Так это же хорошо, что есть люди, которые и вам настроение подымают и актуальные проблемы решают: они знают, что там, где есть возможность платить меньше без ущерба делу, нужно платить меньше, и что им за это, в конечном счете, будут благодарны.
Dr.Death, в PHP 5.3 не очень актуально, но кое-какие улучшения в этом плане имеются (~130 кб на запись AR меньше, чем в 1.1).
Ну тут вопрос больше в клонах, чем в потреблении ими памяти, память это будет побочный эффект :D
Разве этот чудесный фреймворк заставляет лезть так глубоко в код и что-то править? У меня возникает чувтсво, что народу просто заняться нечем
Если оптимизация будет мешать скорости написания/поддержки, то фреймворк будет проигрывать другим, у которых баланс лучше. Считаю, при прочих равных, добавление десятка мегабайт ОЗУ серверу несравненно легче затрат времени на разгребание "ассемблерных" названий переменных. У нас 21 век - время людей должно цениться больше железа.
Убивать так убивать… Еще тогда и комментарии PHPDoc надо вырезать, ибо они сохраняются в байт-коде PHP.
@Vladimir
Не увидел, где они сохраняются в байткод github.com/php/php-src/blob/master/Zend/zend_vm_opcodes.h Ну, а если речь о времени разбора, то, таки да, у Yii на это тоже есть ответ в виде почиканного yiilite.php
@idle
Они сохраняются не как исполняемые инструкции. Посмотрите, например, структуру zend_class_entry — в ней есть поля doc_comment и doc_comment_len — это оно самое (github.com/php/php-src/blob/master/Zend/zend.h#L528).
Функция zend_declare_property_ex() тоже принимает на вход указатель на PHPDoc.
Бех жтого, кстати, функции типа ReflectionClass::getDocComment() не работали бы ;)
По поводу yiilite.php — ну не знаю, на многих серверах у нас оно оказывается медленнее yii.php (а на других — наоборот).
PS: в моих старых тестах основная проблема была связана не с потреблением памяти, а с производительностью.
Для себя мы её решили, написав PHP-расширение, в которое вынесли CComponent, CBehavior и еще несколько классов (попутно избавившись от нескольких проверок, ибо нам всё равно, получить ли Exception от Yii или Fatal Error от PHP).
@Vladimir
Видимо, мы с вами разные вещи под «байткодом» понимаем. Но я понял о чем вы.
@Sam
Провёл небольшой тест: gist.github.com/4687561
На 100,000 объектах разницы в потреблении памяти не видно.
What am I doing wrong?
@Vladimir, в 5.4 аллокация памяти чуть иначе работает, чем в 5.2, 5.3. Вот тут выяснили: github.com/yiisoft/yii/issues/2018
В угоду уменьшения потребления памяти в 10кб отобрать читабельность кода, пусть даже и приватных свойств? Это как стрелять по воробьям из пушки.
А смысл если zval для этих свойств больше памяти занимает?
@Sannis
Казалось бы причём тут zval, когда в статье обсуждаются имена переменных, а не их значения.
Вы ведь не станете спорить с тем, что при любом раскладе телевизор в упаковке не может занять меньше места, чем тот же телевизор без неё %)
как можно получить список всех объявленных с их весом?