james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin (JIRA)" <server-...@james.apache.org>
Subject [jira] Commented: (MIME4J-5) Mime4j takes really long to parse big messages
Date Wed, 09 Jul 2008 19:29:31 GMT

    [ https://issues.apache.org/jira/browse/MIME4J-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612245#action_12612245
] 

Robert Burrell Donkin commented on MIME4J-5:
--------------------------------------------

In terms of performance:

When using Mime4J for mail, there are occasions when the data is available pre-buffered. I
think that this will result in double reading ATM but I don't think it worthwhile to focus
on that right now.

AIUI the shiftTable used by InputBuffer#indexOf depends only the boundary and is a small (255
entry) int array. It is created newly every time that the boundary is searched for. This unlikely
to be a major performance issue in typical difficult use cases (few mime parts each large).
So I don't think sharing the shiftTable would be a major gain.

But in terms of the API, I think that perhaps it might be possible to use a compilation (and
perhaps) cache metaphor without exposing unnecessary implementation details. Here's a sketch
(though I'm sure if you think it worthwhile you'll find a better way). InputBuffer exposes
a private class call Pattern created by a 'compile' method. indexOf is refactored to use Pattern
(rather than bytes). Pattern caches the shiftTable. InputBuffer caches the Patterns it's compiled.

> Mime4j takes really long to parse big messages
> ----------------------------------------------
>
>                 Key: MIME4J-5
>                 URL: https://issues.apache.org/jira/browse/MIME4J-5
>             Project: Mime4j
>          Issue Type: Bug
>    Affects Versions: 0.3
>            Reporter: Norman Maurer
>            Assignee: Robert Burrell Donkin
>             Fix For: 0.4
>
>         Attachments: mime4j-2.patch, mime4j-3.patch, mime4j-4.patch, mime4j.patch
>
>
> From ml:
> Mime4j has general demonstrable performance problems:
> http://buni.org/bugzilla/show_bug.cgi?id=137
> http://blog.buni.org/blog/mbarker/Meldware/2007/01/27/Look-out-Its-behind-you
> I'd suggest a general code review for the "byte at a time + buffered input stream" anti-pattern
> and general refactoring to do things in blocks where possible.
> -Andy

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message