On Thu, May 01, 2003 at 02:31:40AM -0400, Aaron Sherman wrote: > On Wed, 2003-04-30 at 17:49, Nicholas Clark wrote: > > Ah. I'm not sure which situations copy on write will give you a win over > > simple passing a scalar reference and dereferencing it as needed. There > > doesn't seem to be any copying for that for the simple test that I did: > > The problem in SA is that it does (massive paraphrasing into pseudo-code > here): > > sub processmessage { > my $self = shift; > my $msgref = $self->{message}; > $self->{msg_as_array} = [split /\r?\n/, $$msgref]; > $self->process(); > } > > It does have good reason for this, and there are large performance > benefits, but it is a big hit on memory. > It does seem here like you're saying I'm hoping in vain, since the above > code is certainly not allocating PVIVs... perhaps split// is one of > those cases that should have such optimization forced...? I don't know. Given that you're competent and happy to hack with magic, I think it's best if you use your intuition to try tweaking bits of the core. I'd like to say "use a profiler" given that profilers are almost always better than intuition, but it sounds like you've already identified that the problem is more memory than CPU, and I'm not sure if there is any good way to profile memory usage. > > I don't know. There are no good benchmarks to test this kind of thing. > > Heehee, welcome to SpamAssassin, the Perl benchmark from hell! ;-) Well, if the SpamAssassin team produced a benchmark type thing (with pre-supplied "typical" spam for separate download for definitive comparison tests) it would at least give us (on p5p) a target to shoot at for speedups. This is not quite as crazy at it may seem, as I think I rad somewhere recently that even die-hard perl haters install perl just to run SpamAssassin. And it's a real performance hog, more so that most other things run by most people. In which case tweaking perl in ways which we know would help a lot of people. Although I'd prefer to simply incarcerate all spammers in camp X-Ray. Nicholas ClarkThread Previous