* Trond Michelsen (trondmm@xxxxxxxxxxxx) [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
Mark@xxxxxxxxxxxx solutions@xxxxxxxxxxxx
http://Mark.Overmeer.net http://solutions.overmeer.net
|
