Hashing, take 2

Andreas Ericsson ae at op5.se
Wed Jun 29 16:26:05 CEST 2005


Andre Bergei wrote:
>>-----Original Message-----
>>From: nagios-devel-admin at lists.sourceforge.net 
>>[mailto:nagios-devel-admin at lists.sourceforge.net] On Behalf 
>>Of Andreas Ericsson
>>Sent: Wednesday, June 29, 2005 10:51 AM
>>To: nagios-devel
>>Subject: [Nagios-devel] Hashing, take 2
>>
>>I've decided to drop the massive hashing code changes I 
>>submitted last time. This new patch is minimally intrusive 
>>and seems to work nicely. I haven't tested this in production 
>>very much, but it seems sound enough (cgi's run OK from 
>>command-line, nagios -v has no problems).
>>
>>This is much less intrusive. Please test/use this patch instead.
>>
>>-- 
>>Andreas Ericsson                   andreas.ericsson at op5.se
>>OP5 AB                             www.op5.se
>>Lead Developer
> 
> 
> Hi.
> 
> Does this patch speed up the cgi's?

Slightly, yes, but a different amount on different systems based on the 
conditions below. The greatest benefit will be for systems that accept a 
receive a large amount of passive checks though.

On systems where strlen() isn't a compiler intrinsic it will provide a 
fairly large boost.

If you used to have lots of collisions with the additive hash previously 
used you should see a fairly nice improvement (there's no way of knowing 
how many collisions you had per bucket without hashing all of your data 
with both algorithms and comparing it). Typically, networks with a 
proper naming-standard has many collisions with additive hashes.

Systems where strcmp() isn't a compiler intrinsic, or where 8-bit 
operations are terribly expensive, will see a vast improvement, although 
this depends largely on the condition above as well as the number of 
elements monitored.

Systems with a large call overhead will benefit greatly as the 
hash-functions and some of the hash-comparison functions are inline.

Systems where the compiler does poor branch-prediction should see some 
fairly large improvements.

Very small installations will notice a very slight performance 
degradation (actually, they won't notice it because pages will appear to 
load instantaneously anyways).

> If so i'm willing to take it for a spin and report my findings.
> 

Please do. The main issue at hand here is stability at first. If this 
patch works out well we can start chopping up the code to be better 
compartmentalized and each section of it can then be optimized to the 
extremes wrt both resources and speed without having to gamble with 
stability.

As for the GUI, it would need a complete re-design that would also 
affect the core for it to be noticably faster. Ethan's not willing to do 
that (I agree with him) since the effort would be wasted once the new 
GUI emerges.

> Best
> Andrè
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
> 

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click




More information about the Developers mailing list