Robert Burrell Donkin ha scritto: > On Sun, Dec 14, 2008 at 8:35 PM, Markus Wiederkehr > <markus.wiederk...@gmail.com> wrote: >> Sorry about my last comment on MIME4J-66. I did not realize that it is >> about Base64Encoder, not Base64OutputStream.. >> >> But is Base64Encoder really necessary? I mean >> CodecUtil.encodeBase64(InputStream, OutputStream) could also be >> implemented as: >> Base64OutputStream b64Out = new Base64OutputStream(out); >> copy(in, b64Out); >> b64Out.close(); >> >> Why maintain two versions? > > copy uses more memory and is slower
"encoder.encode" does nothing different than "copy". encode reads a byte[] buffer from IN, encode it in another byte[] and then write it to OUT. the outputstream based copy instead: reads a byte[] buffer from IN, calls the write, write encode it in another byte[] and then writes to OUT. The bytes are copied the same number of times. >> I also noticed that CodecUtil.encodeBase64 is not called anywhere in >> Mime4j. Could we remove it entirely? >> >> The same arguments apply to QuotedPrintableEncoder and >> CodecUtil.encodeQuotedPrintable.. For QP it's not the same. QuotedPrintableOutputStream and CodecUtil.encodeQuotedPrintable use the same underlying encoder to do the encoding (QuotedPrintableEncoder). Instead the Base64 encoding is present as 2 different implementations. > these methods are more performant but less well tested. take them out > if you like. While architecturally speaking it *may* be true, this is FALSE for the current implementation. At least my last outputstream was already faster than the encoder. Markus say that the new outputstream is twice faster than my outputstream, so it should be a lot faster than the encoder. Unless we start using directly byte[] buffers if we use inputstreams and outputstreams there is no difference in the needed copy between the 2 patterns. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
