On 7/1/09 5:05 PM, John Hampton wrote: > Shane Caraveo wrote: >> From what I've seen so far, IRequestHandler.match_request and >> ITemplateStreamFilter.filter_stream are two area's where performance can >> (and is) hurt by plugins doing more than they should. I'm not certain >> the issue is those mechanisms specifically, but rather how they get >> used. Just one example, not picking on anyone as I have several >> examples, the timing and estimation plugin is a major user of stream >> filters, and in some cases more than doubled the request times. > > So, not quite sure what one would be doing in match_request to make it > take a long time (permission checks, perhaps?),
I've seen permission checks, uncompiled regex matching, and other more minor things. It seems to me anything other than a req.path_info.startswith(/mypath) is too much. I wonder if there would be a better mechanism for this. > but StreamFilters will > definitely affect performance, as you have discovered. This is due to > genshi. I know that some work was done on making some speed > improvements in this areas (or maybe it was just template includes). > However, it's just an expensive process. There's definitely some improvement in genshi trunk, but it's still slow. I've profiled some basic requests, genshi 5 takes around 25% of the request time. With trunk it's down to probably 20%. It seems to be primarily the xpath matching, but it's hard to tell, combining kcachgrind with python profiling is sometimes odd. :) On my system, it seems a large part of that is due to path matching from stream filters. Shane --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
