This time, with the patch attached.
On Nov 8, 2007 9:56 PM, Kaul <
mykaul@xxxxxxxxx> wrote:
I've fixed ep_strndup <-> se_stnrdup, patch attached.
From subjective testings, it seems that there is some measurable performance improvement - 5-10 percent on my test pcap file (~
you are not just avoiding a strncmp(), but also the char-by-char search for the space that follows the method (as well as another strncmp() for 'M-', which is a rare case as well). The optimization, while not the cleanest coding-wise, works well because it works for the most common cases - and I believe many, many times (subjectively > 90%) of the times it'll hit the optimized path.
Nevertheless, it is important for me that it'll be understood - so I documented it inline clearly - I think.On Nov 8, 2007 2:12 AM, Stephen Fisher <
stephentfisher@xxxxxxxxx> wrote:
On Mon, Nov 05, 2007 at 09:15:45AM +0200, Kaul wrote:
> Somewhat inspired by the performance improvements to tvbuff, I've made
> some small performance improvements to packet-http.c:
> 1. In the most common cases 'GET ', 'POST', 'HTTP' - compare them
> against the 32bit value of those strings, instead of strncmp(). I
> reckon in most cases it'll be used, and there won't be need for longer
> comparison paths.
Is this a significant enough performance improvement to warrant making
the code a bit harder to read, maintain and understand? The strncmp()
function, at least in a recent FreeBSD libc, looks pretty quick and
simple as it is. I am just wondering; I do not mean to discourage you
from you from contributing.
Steve
Attachment:
packet-http.c.diff
Description: Binary data