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 -~----------~----~----~----~------~----~------~--~---
