Thanks for the response Matt. My profiler says that lot of time is spent on fetching data and executing setMultiOptions on select elements. I guess caching can help.
Only I'm thinking about caching strategy... Will get back after optimization... Regards, Saša Stamenković On Wed, Sep 30, 2009 at 2:47 PM, Matthew Weier O'Phinney <matt...@zend.com>wrote: > -- umpirsky <umpir...@gmail.com> wrote > (on Wednesday, 30 September 2009, 12:43 AM -0700): > > I have this form: > > <snip> > > > During the form initialiation, I'm performing 2 queries to get options > for > > selects: > > 0.00131 SELECT `brand`.* FROM `brand` ORDER BY `title` ASC > > 0.00082 SELECT `location`.* FROM `location` ORDER BY `title` ASC > > which are pretty fast as you can see. > > How long does it take to connect to the database, though? Personally, > I'd cache that information to ensure it does not become a bottleneck. > > > Form constructor (initialization) takes 3.11 and rendering takes 2.25 > > seconds. This numbers depends on server speed ofc, but still pretty slow. > > What ZF version, PHP version, and OS are you using? It shouldn't be > taking that long -- I've rendered many forms with > 10 elements that > initialize and render in fractions of a second. > > That said, one place we've identified for improvement is sharing plugin > loaders between elements. As it is, each element instantiates its own > plugin loaders for validators, filters, and decorators -- which leads to > duplicate processes running in many cases, and has presented a > bottleneck when you have many dozens of elements. We'll start this > refactoring soon, but I have no ETA on when that will happen. > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ >
