Вопрос по дополнительной нагрузке на сервер?

Question

[Sergey Zhukov]

Господа, имею есть расширение nested sets, Но важно не это. Например когда я запрашиваю паравозик в переборе:

<?foreach($row->getImages()->all() as $image):?>
    <li class="<?if($row->getImages()->all()[0] == $image):?>active<?endif;?>"> blahblah</li>
//... и еще до кучи

if(end($row->getImages()->all()) == $image)) //...
 <?endforeach;?>

Есть ли разница по нагрузке, от того, если я сначала сохраню весь результат:
$result = $row->getImages()->all() ;
И буду его перебирать и обращаться к нему ($result). Будет ли существенная(*) разница в производительности? Или плевать? Как вы поступаете?

Answer 1

[Сергей Протько]

Как вы поступаете?

Я пишу нагрузочные тесты.

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

p.s. А где twig? у него все эти задачи уже давно решены (вроде проверки является ли элемент первым) и причем весьма эффективно.

Comments

[Sergey Zhukov]

Интуиция это хорошо, но array_shift вы хотели сказать :) (есть end и array_shift) twig не пользовал, почитал пользователей и отзывы, чет не сильно разницы вижу в нем, только срачи разводят

[Sergey Zhukov]

Вот поэтому и спросил, вгружены или нет. Т.е. я предполагал, что если я еще раз вызову "паравозик", то он снова в базу пойдет.

[Сергей Протько]

Сергей Жуков: не array_shift, а $collection->first(). array_shift меняет массив а нам это не надо.

[Сергей Протько]

Сергей Жуков: ну и вместо end($collection->all()) - $collection->last() (внутри собственно тот же end и вызывается).

Что до twig - я не знаю что вы там читали и мне в принципе без разницы. PHP отвратный шаблонизатор.

[Sergej]

Сергей Жуков: Советую вам перечитать про twig.
Вы как минимум делаете код не читабельным и более громоздким.
Не говоря уже про функционал и удобство.

[Сергей Протько]

Sayber ☠: я вообще не понимаю людей которые не используют шаблониазторы... Буквально на днях делал аудит одного проектика где люди так же отказались от оных... XSS уязвимости это норма для таких приложений.

[Sergej]

Сергей Протько: Я познакомился с symfony за счет шаблонизатора twig =)
До этого был zend.

[Андрей]

Ну вроде как по умолчанию кеширование запросов на самом MySQL включено, можно сделать принудительное кеширование запроса, можно самому результат покласть в кеш и брать оттуда.. Как писали ранее напишите тест и посмотрите.. Но если вы сразу занялись оптимизацией, я бы пока не стал, если сервер справляется и за приемлемое время то пусть работает, просто поставил бы галку что если надо что то подкрутить то крутить тут и тут. И тесты рулят! )

[Сергей Протько]

Денис Иванов: шаблонизаторы не панаценя, согласен, но они сильно снижают такие риски. Ну и повторюсь - php так себе шаблонизатор с точки зрения поддержки шаблонов.

[Сергей Протько]

Денис Иванов: "проектировался как шаблонизатор" это то да, да только повторюсь. Очень плохой шаблонизатор, не слишком гибкий, увеличивающий дублирование и сложность поддержки и т.д. Но для Си это был хороший шаблонизатор, да, на то время.

И опять же, времена PHP3 уже думаю прошли давным давно.

[Сергей Протько]

Денис Иванов: не совсем. Скажем у twig (как и у многих других шаблонизаторов нынче) есть наследование шаблонов и система блоков. В PHP реализация оного приводит к куче дополнительного кода, шаблоны становятся менее читабельными и единственный вариант как это все разруливать - инклуды и функции выплевывающие html в буфер вывода. Имхо это не слишком читабельно и не слишком удобно. За те 20 лет что существует шаблонизатор PHP люди понавыдумывали намного более гибкие решения которые больше подходят для этих задач.

[Sergey Zhukov]

вот про эти срачи я и говорил

[Сергей Протько]

Денис Иванов:

использовать виджеты из Yii

1) откуда у нас Yii?
2) виджеты это как раз таки кастыли в виде инклудов, в контексте Yii это недо-реализация HMVC.

Не вижу смысла в шаблонизаторах.

Я не вижу смысла в Yii, но судя по всему вам оно нравится.

Сергей Жуков: да, находятся кадры. И имено код таких чуваков (любители Yii и нелюбители шаблонизаторов) я сейчас наблюдаю и делаю аудит... и там все грустно.

[Сергей Протько]

Денис Иванов: грусто наблюдать за теми кто не понимает различия между снижением рисков и "спасением от всех бед".

Yii так себе фреймворк, особенно 1.x версия. Поверьте, я с ним работал достаточно плотно. Версия 2.x далеко не ушла, а проекты лучше не стали.

[Сергей Протько]

Денис Иванов:
1) ну так а я предлагаю богомерзский смарти? Есть twig, он покрывает все нужды. + его очень легко расширять под проект. А шансы что разработчик с php шаблонами забудет заэкранировать какие-то вещи сильно повышается, повышаются риски. Так же стоимость поддержки так же может существенно возрасти. Если вы знаете о рисках - то нет проблем, но большинство не знает.

2) сильное связывание компонентов (для версии 1, для второй все чуть получше), откровенно слабое комьюнити. В принципе для простых проектов и для быстрой разработки норм, но.... вот у меня сейчас перед глазами проектик... ~3000 коммитов, 70К строк кода. За счет отсутствия контейнера зависимостей - фреймворк потворствует нарушени принципа инверсии зависимостей, все связано друг с дружкой и т.д. В итоге масса регрессий на пустом месте.

На Yii можно писать хорошо, и многие пишут на нем хорошо. Я работал с Yii со времен 1.0. Но для этого должен быть недюжий опыт, годы хождения по граблям и т.д. Именно это для меня является основным показателем "хорошести" фреймворка. Yii потворствует плохому дизайну (та же проблема например у angular1). Хоть во второй версии Yii получше все стало, но на фоне Laravel я реально не вижу в нем смысла (зачем плодить сущности?). Он принципиально от него не отличается и часть решений банально хуже. Комьюнити существенно меньше. Риски выше.

В целом же основная болезнь людей пишущих на Laravel/Yii и других RoR подобных PHP фреймворках, является то, что они пытаются перенести философию RoR в пых, без принятия любви рубистов к тестам. Ну и да, типичная проблема - высокая связанность бизнес логики и фреймворка. Люди пишут на фреймворках а не на php. У Symfony/zend тоже есть эта проблема но чуть меньше выражена.