Christian Boos wrote: > John Hampton wrote: > >> Noah Kantrowitz wrote: >> >> >>> This is a bug in Genshi, and I don't want to start talking about >>> workarounds until it is clear there is no way to fix it directly. >>> >>> >> I have to agree with Noah here. The change should not have any impact >> on Trac. That it is highlights the issue with the template engine we >> have chosen. >> > > 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 ;-) > 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. 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. The same way, I think it's still worth considering optimizing individual templates like report_view.html, to /gain/ 20% speed. -- Christian > That conversion is nearly trivial and would need to be done only for the > more demanding templates, the others could still use the <py:match> > based layout.html (which in turn would now be <xi:include>ing the same > smaller snippets - so no template duplication). > > >> The fix should be done in the template engine also. If it >> turns out that there is no way around it in the template engine, then I >> think we need to think really hard about using Genshi. >> >> > > Let's not throw out the baby with the bath water ;-) There's more to > Genshi than just the <py:match>. I totally agree that using <py:match> > is way more powerful and elegant than using <xi:include>, but that's > really not the point. Let's try to make Trac usable with what we have > now and use <py:match> liberally when/if it gets fixed, not the reverse > way round. > > -- Christian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
