Found nn messages in the processing-messages database

[Glenn Steen]

2009/4/20 Julian Field <MailScanner at ecs.soton.ac.uk>:
>
>
> On 20/04/2009 13:40, Glenn Steen wrote:
>>
>> 2009/4/20 Kai Schaetzl<maillists at conactive.com>:
>>
>>>
>>> Anyway, the point is, that many of us will simply don't need this. It's
>>> just
>>> some more milliseconds added to processing. In the recent past people
>>> have
>>> already complained several times about performance. Why hamper
>>> performance
>>> where it is not necessary?
>>>
>>>
>>
>> I think Jules is aiming at microseconds...:-). And as such, well spent;)
>> Who knows, perhaps one should do it as an option ... Like: if you use
>> the processing DB, then you get deterministic "entropy" added to the
>> queue file name, else you get the regular entropy as we have had for
>> quite some time now.
>>
>
> I don't intend adding a configuration option for something as small as this.
> The overall effect on speed will be tiny, it just has to read 256 bytes out
> of a file that it will be about to read into memory anyway, so the cost does
> not involve a single disk read, it will be in memory buffers anyway. I would
> be interested to see if you can actually make the load difference measurable
> on a real system.
>
> I deliberately and carefully chose a checksum algorithm that would work as
> fast as possible while providing the necessary resilience that it's there
> for. It is far faster than a CRC check, let alone something crazy like MD5.
> If you read the code, you can work out the number of add and mask operations
> that are used in its implementation. It doesn't involve a single multiply or
> divide operation, just bit-masking and adding.
>
> And furthermore, 99.99% of users would never change the option as they
> wouldn't understand it, and I try to avoid having tweaks that only 1 user
> will ever change. And don't forget that it costs time to evaluate a
> configuration option, they aren't free.
>
> You have the source. If you don't like it, supply your own PostfixKey
> subroutine in Postfix.pm.

Hm. Ok. I meant that the already present option could be used;-).
No matter. One sleek implementation will fit my needs perfectly.

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se