Re: memory usage when saving attachments

* Trond Michelsen ([email protected]) [040401 15:38]:
> So, MIME::Parser uses 400kB to decode an 8MB mail, and Mail::Message
> uses 27.5MB. In addition, Mail::Message uses 41MB to read the message
> from a filehandle.

You gave your own answer: MIME::Parser writes by default everything
to file, and Mail::Message by default everything to memory.  MailBox
does have a way to have message bodies stored in files, but not with
MM::read()... I have aadded this as feature to the next release. You
may fix is temporarily by changing Mail::Message::Construct::Read
    $self->readFromParser($parser);
into
    $self->readFromParser($parser, 'Mail::Message::Body::File');

> These numbers surprise me, since Mail::Box uses a lot of lazy loading
> techniques to save memory. But it doesn't seem like this is the
> default with Mail::Message objects. Am I doing something horribly
> wrong to get these results?

MailBox is quite optimal for parsing folders.  In that case, you can
do a lot of nice things, like being lazy and predicting body size and
thereby determining the optimal body storage.  However, for messages
which come from stdin, it is not that smart.

> One other thing - The attachments that are decoded from Mail::Message
> seem to be consistently 1 byte larger than they are when decoded by
> MIME::Parser. It seems that they somehow attract an extra newline at
> the end.

That's because of the older MailBox version you use.  In the current
version it won't.  It had to do with the following: when you do this
   my $body = Mail::Message::Body->new(data => "one line");
your body will be corrupt: it lacks the newline at the end.  Therefore,
someone suggested to see wether there was a new-line, and add one if
there is none.  The problem is that decoding does something like
   my $dec = Mail::Message::Body->new(data => decode($body->string));
but the decoded information could be binary, and shouldn't be modified.
So I have removed the smart "\n" addition one release later.
-- 
               MarkOv

------------------------------------------------------------------------
drs Mark A.C.J. Overmeer                                MARKOV Solutions
       [email protected]                          [email protected]
http://Mark.Overmeer.net                   http://solutions.overmeer.net