[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mandating PERL for ZMailer system ??



On Tue, Apr 11, 2000 at 06:53:24AM +0200, Matthias Urlichs wrote:
> Andy Poling:
> > > [ Marrying Perl and Zmailer ]
> > 
> > He should have - it violates one of the primary goals of zmailer:
> > efficiency.
> 
> On the other hand, it would allow us to get rid of a lot of cruft,
> including the idea that you can do without reasonable memory management.

	Do you mean to imply that ZMailer's current conscell garbage collect
	system isn't reasonable ?   It has shrunk my systems memory usage
	rather dramatically.
	(Expanding large lists still keeps the beast under 4 MB core memory
	 print at 32-bit SPARC..)

	I do find Perl's external modular DBs an appealing thing to be
	able to interface to, but I would not redo the entire thing
	in Perl just for that.

	My original question was more along lines of mandating PERL
	in operational environment for doing various system management
	things in it, instead of writing yet more C..

> NB, sort-of-completely-unrelated question: Is there a sensible reason
> why Zmailer doesn't do any negative cashing? It would seem that
> fixing this would be _really_ trivial.

	How often do you run cache on at all ?
	Cache algorithm efficiency is currently bad, I reworked it somewhat
	recently to make LRU insert to be O(1), while it isn't full, but still
	lookups are O(n), although now with *small* constant C per each step.
	(LRU cleanup on data expiry happens during lookup scans.)

	A LRU with doubly-linked list and hash indices might work to make
	things more along lines of O(1) for lookup, O(1) for insert, and
	O(1) for tail replace.  Still it would need O(n) for expired data
	removal.

	Whatever method is used, a 10 000 entry cache isn't going to be
	quick to lookup/clean.

	Considering it, presume you have an external socket interfaced DB
	(like LDAP) using cache, you notice that something is missing, you
	insert the data, but then have to wait for same time as the positive
	cache waits before next lookup of same key.

	I did insert an "#ifndef DO_NEGATIVE_CACHE" into appropriate place,
	but didn't define that variable -- yet.

> -- 
> Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
> The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/

-- 
/Matti Aarnio	<mea@nic.funet.fi>