So it appears I have been out-voted on this, so I will return to using the previous loadpaths hack for theming. This does come at a cost though, we need (for whatever definition of "need" we normally use for in-version API stability) to not change the data structures passed to layout.html. I will try to set things up in ThemeEngine to make it transparent when we re-split layout/theme.
--Noah On Mar 26, 2008, at 1:40 PM, Christopher Lenz wrote: > > On 26.03.2008, at 14:41, Christian Boos wrote: >> Christian Boos wrote: >>> I agree with the "should". Yes, "ideally" the problem should be >>> fixed at >>> the Genshi level. ... >>> Coming up with a similarly good fix that would work even with r6696 >>> will >>> most certainly require a major rewrite of the Genshi match logic - I >>> don't even know what could be that approach, maybe cmlenz has some >>> ideas. >> >> And indeed he had (cmlenz rules!), apologies for having doubted >> here ;-) > > I hope to resolve the remaining issues and check in the change this > week. And with that out of the way, a release of Genshi 0.5 should be > a lot closer. > >>> But frankly I think it's /very/ unlikely that it could work with >>> similar speed and memory usage, and that it could be available in a >>> reasonable time frame. >>> >>> Alternatively, not using <py:match> and only <xi:include> gives us >>> nearly the same results for memory usage than with the >>> match_unbuffered >>> patch (even slightly better) and in addition, gives us a 20% speed >>> increase, which, in these days where everyone discovers the >>> performance >>> drop compared to Trac 0.10.x, is not something that we can neglect: >>> - 28.2MB and 12.6s for /report/1 with <py:match buffer="false">, >>> - 27.7MB and 9.9s for /report/1 with <xi:include> >> >> Now with match_unbuffered3.py, the numbers are similar: 28.2MB, and >> 12.9s (on r6692). >> Even more important, the memory usage stays remarkably low, i.e. with >> /report/1 I only see a leak of +/- 48k per request, which is about >> the >> same I have when rendering to .csv. It seems that now Genshi is out >> of >> the picture for the remaining leaks. > > Nice. > >> Unfortunately, with the additional <py:match> brought by r6696, the >> speed impact is quite visible: the average time needed for rendering >> /report/1 is there 15.2s (i.e. 20% slower). >> So I think it's still worth asking the question whether the r6696 >> change >> is worth its performance impact for all users. > > While conceptually I think the theme split is the right thing to do, I > agree that it should probably be postponed to after the 0.11 release. > There'll hopefully be more performance work in Genshi especially on > the match template side (for example, static match templates would > make such simple match templates a "compile time" thing, with no > performance impact at render time). > > But also note that many people will run into the same theme.html > performance degradation simply by using the site.html mechanism. So in > the longer term it really must be improved in Genshi itself (and it is > being worked on). > > But for the short term I think the theme/layout split should be backed > out and reapplied on trunk after the 0.11 branch has been created (and > possibly backported to 0.11.x if improved versions of Genshi become > available). The benefit just doesn't outweigh the cost right now. > Sorry Noah :P > >> The same way, I think it's still worth considering optimizing >> individual >> templates like report_view.html, to /gain/ 20% speed. > > And I still think we should strongly consider integrating the > pagination patch for queries and reports. Has anyone been looking into > that? What ticket is it again? :P > > Cheers, > -- > Christopher Lenz > cmlenz at gmx.de > http://www.cmlenz.net/ > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
