I was trying to diganose the big difference between total query time (~ 37 milliseconds) and total page execution time (~390 millisecond) and I found that video filter module adds significantly even on pages "video" tag is not used. This was a fairly large text intensive page and I expected every filter will add overhead. BUt the time difference with video filter was most significant.

Please note the video filter was the on the top of filter chain (least weight) among all modules. I have not tested with changing weight if there is any difference.

Total page execution time for 243 queries taking roughly 37 milliseconds
with video filter

386 milliseconds
390 milliseconds
387 milliseconds

After Disabling video filter

214 milliseconds
251 milliseconds
210 milliseconds

Comments

blackdog’s picture

blackdog commented
Status: Active » Closed (fixed)

I'm not really sure what to do about this, as video filter grows with more codecs, there will be added time to go through a text intensive node to check for matches.

ajayg’s picture

ajayg commented
Status: Closed (fixed) » Active

I can understand.

However as I mentioned above, if there is no video tag at all on the page should there be such overhead? Other filters do not add such huge overhead if their corresponding tag is not in the text. So I am thinking video module could check if there is a video tag first, before even attempting further processing. So checking page "video" match first and if it is not there simply returning may do the trick (I think)

blackdog’s picture

blackdog commented

I'll take a look at this to see if there's something to do about this. Thanks!

blackdog’s picture

blackdog commented
Status: Active » Fixed

I've looked through the code, and I don't believe this module can behave any differently than it does. We do check for matches for [video] before doing anything else, and I've also cleaned up the code a bit in #537246: op "no cache".

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.