Theo Van Dinter writes: > On Thu, Apr 13, 2006 at 04:03:54PM -0500, Michael Parker wrote: > > > - persistent DB connections (suggested by Michael last year) > > > > This exists, but is not an ASL friendly license. So a "clean room" > > implementation might be cool. > > I also suggested having things like Bayes expiry and such being passed back to > the parent who can spawn a helper process to do the work. That way the > children processes will be able to accept, process, return the result, notify > parent for bayes work, go back to listening. Right now we do: accept, > process, do bayes work, return result, go back to listening, which ends up > causing timeouts and possibly eats up all processing children.
That would be cool. > > C implementation of the Message object. > > Not necessary IMO. Message parsing is very fast the way it is, and it's > such a tiny amount of time in relation to the other places which need > more attention. I agree on this too. > We can make Message and Message::Node a little more resource efficient > though. I have some thoughts about putting message parts we don't > need or use often in temp files (pristine copy, non text/* parts, etc,) > replacing recursive method with a queue system instead for parsing and > find_parts(), etc. One thing btw is to turn arrays into strings -- strings are much more memory-efficient than perl arrays (but are quite a bit slower for some operations, so it's a trade-off). > Related to this, I have a feeling we cache the same data multiple times > and possibly unnecessarily throughout the code. I haven't dug around > to pinpoint areas which need addressing, though I did add in some code to > streamline header tests to order the tests such that there are a minimal > number of calls to PMS::get(), etc. > > > Performance improvements in general. There might even be some low > > hanging fruit already in Bugzilla (see C TextCat implementation that > > just needs to be updated to the latest and greatest). > > Yeah, I don't know how we can really quantify "in general" though. > Making a project to get SA faster by X % or something isn't likely to > get picked up imo. Yeah -- too woolly and vague. Plus there's a danger they'd improve the speed by simply breaking other (slow) stuff ;) > TextCat could be sped up, but I don't think that's > where most people find a bottleneck. still, probably worth doing maybe! > Figuring out how to parallelize rules may be good. hmm, but that's right in the core of PerMsgStatus -- having inexperienced coders hack away at that is a recipe for disaster I think. If you think the current situation with bugs 3109, 4776, and 4778 is messy, imagine what it'd be like without experienced people working on it :( --j.
