You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2006/11/27 22:47:21 UTC
Re: svn commit: r479728 - /spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm
by the way -- with that change, after a mass-check of a couple of
messages:
1 1000 1001 986 24 0 37668 33636 pipe_w S+ pts/8 0:01 /usr/bin/perl -
without:
1 1000 1270 1255 24 0 37660 33608 - R+ pts/8 0:01 /usr/bin/perl -
so the "before" version saved a few KB.
--j.
felicity@apache.org writes:
>Author: felicity
>Date: Mon Nov 27 11:20:20 2006
>New Revision: 479728
>
>URL: http://svn.apache.org/viewvc?view=rev&rev=479728
>Log:
>if a temp file's contents are read back in, we may as well continue to store that information in memory.
>
>Modified:
> spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm
>
>Modified: spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm
>URL: http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm?view=diff&rev=479728&r1=479727&r2=479728
>==============================================================================
>--- spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm (original)
>+++ spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm Mon Nov 27 11:20:20 2006
>@@ -265,6 +265,8 @@
>
> # Ok, if we're called we are expected to return an array.
> # so if it's a file reference, read in the message into an array...
>+ # and since we're already sucking up the extra RAM to load it back in, store
>+ # the reference.
> #
> # NOTE: that "ref undef" works, so don't bother checking for a defined var
> # first.
>@@ -273,7 +275,8 @@
> my $fd = $self->{'raw'};
> seek $fd, 0, 0;
> @array = <$fd>;
>- return \@array;
>+ close $fd;
>+ $self->{'raw'} = \@array;
> }
>
> return $self->{'raw'};
>
>
>
Re: svn commit: r479728 - /spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm
Posted by Theo Van Dinter <fe...@apache.org>.
On Mon, Nov 27, 2006 at 09:47:21PM +0000, Justin Mason wrote:
> by the way -- with that change, after a mass-check of a couple of
> messages:
>
> 1 1000 1001 986 24 0 37668 33636 pipe_w S+ pts/8 0:01 /usr/bin/perl -
> 1 1000 1270 1255 24 0 37660 33608 - R+ pts/8 0:01 /usr/bin/perl -
>
> so the "before" version saved a few KB.
I reverted the change. I figured the loading would cause the bump that
wouldn't be recovered, but in certain situations it makes sense that
less memory would be used since the data is probably used quickly and
thrown out (decoding, etc.)
--
Randomly Selected Tagline:
"What happened? You all look like a pak-mara ate your cat."
- Ivonova on Babylon 5