What happens if you run the query manually against the database? Could be that you're doing a non-optimized join or so...
Daniel On Sep 6, 4:13 am, Hugo Chinchilla <hugoase...@gmail.com> wrote: > Hi, > > for my app's backend I have written a custom method to draw a select > widget which was consuming a lot of memory to generate. > > The default form generated a select widget from the model populating > full objects just to render an options list which only needs a PK and > a string, so I wrote a method which generates a new sfWidgetFormChoice > and fills it with choices from a custom query which retrieves only 3 > columns, the PK and other 2 to compose the option name. > > The memory consumption is now 20M less than the original, but the time > it takes to generate the page has increased from 600ms to more than 3 > seconds. The time profiler in the debugbar shows that all this extra > time happens on the rendering of the form. > > I can't understand this behaviour because the sfWidgetFormPropelChoice > extends sfWidgetFormChoice, so the rendering is the same, the only > difference is the way in with the $choices array is generated -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
