[
https://issues.apache.org/jira/browse/MIME4J-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606996#action_12606996
]
Oleg Kalnichevski commented on MIME4J-5:
----------------------------------------
I do not want to put unnecessary efforts into refactoring a lot code if it is
bound to be replaced anyways. However, I feel the greatest bottleneck is the
MimeBoundaryInputStream backed by the PushbackInputStream. I'll _try_ to
rewrite this class with the minimal impact onto the rest of the codebase, which
should improve the situation quite a bit.
I doubt that the use of NIO will automatically result in any performance
improvements based on my experience with classic I/O and NIO HTTP transports in
HttpComponents.
Oleg
> 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: Niklas Therning
> Fix For: 0.4
>
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
