Минимизация размера кеша

  • Автор темы Автор темы Koc
  • Дата начала Дата начала
1200 это фигня, не должны тормозить ни доктрина, ни твиг. В каком виде дерево хранится? Где-то явно лишние итерации гоняются.
 
Если дерево добывается рекурсией через чуть менее 1200 SQL-запросов, то доктрина действительно непричем :)
 
1200 это фигня, не должны тормозить ни доктрина, ни твиг. В каком виде дерево хранится? Где-то явно лишние итерации гоняются.
дерево хранится в виде списков смежности + closure table. Ну мы ж выгребаем все дерево сразу, запрос тут простой select * from category и все. Он один.

Если дерево добывается рекурсией через чуть менее 1200 SQL-запросов, то доктрина действительно непричем :)
а тебя в пыховском чатике нету? Есть скайп?
 
Koc
то есть проблема только в коллекции с ийтемами, которую делает доктрина, нужно её либо сразу вытаскивать как массив, либо достав превращать в массив. не занимался вопросом больших коллекций, но есть же методы типа toArray, либо гидратор ARRAY.
 
неет, я еще не профайлил, я писал это неоднократно).

toArray нельзя, там есть определенная логика с сущности, мол если такое-то поле равно тому, возвращаем се, в противном случае - то.
 
Redjik
разве что профайлинг-трейс сделать и посмотреть на какой вызов время уходит, мне кажется там основная проблема в обёртывании всё в коллекию, а внутри коллекции объекты с записями и не дай бог ещё lazy load из closure table
 
Redjik
фу, она же на медленной java, у меня даже webgrind быстрее работает. а линкусе kcachecgrind и вовсе красотищу рисует, в винде wincachegrind чуть похуже, но всё равно лучше её
 
Сверху