http://bugzilla.spamassassin.org/show_bug.cgi?id=4260





------- Additional Comments From [EMAIL PROTECTED]  2005-05-09 05:32 -------
I'm getting a very strange result and can use some advice from people with more
perl expertise.

I made the following changes in DnsResolver.pm

I generalised the use of the id by adding an argument to the closure that is
passed to bgsend. Instead of it having one argument of the answer packet and
then defining it in Dns.pm to save packet->header->id, I made it have two
arguments, the second one being whatever bgsend uses as the id key. That way
when I change the key there is no change required in Dns.pm.

I then changed bgsend and poll_response to use $id . $host instead of just $id.

I'm leaving out a few details, but it all ran ok.

However, it was very slow. Investiating, I found that it was just about as slow
if I simply set $id = $id . "x", i.e., make it a nonumeric string.

The only difference was whether the $id key was an integer or a string in these
two places:

  $self->{id_to_callback}->{$id} = $cb; # in bgsend
and
  my $cb = delete $self->{id_to_callback}->{$id}; # in poll_responses

Debugging output showed that there were between 20 and 30 of these per message.

When $id is an int, the mass-check processes about one message per second.

When $id is a string, mass-check processes about one message every four seconds.

How could 40 to 60 associative hash references take that long?




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

Reply via email to