<br><br><div class="gmail_quote">On Fri, Nov 20, 2009 at 7:44 PM, Thorbjoern Ravn Andersen <span dir="ltr"><<a href="mailto:ravn@runjva.com">ravn@runjva.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Maarten Bosteels skrev:<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
XMLEncoder will have a severe impact on performance, I've tested<br>
this extensively.<br>
Have a look at<br>
<a href="http://sourceforge.net/apps/trac/lilith/wiki/SerializationPerformance" target="_blank">http://sourceforge.net/apps/trac/lilith/wiki/SerializationPerformance</a><br>
In my testcases, XMLEncoder serialized 300 events while a protobuf<br>
serializer managed to handle nearly 10.000!<br>
I'd therefore suggest that you take a mixed approach. Using<br>
protobuf to serialize the events to a file and writing an<br>
additional converter to convert that files to whatever you'd like<br>
as XML-Output as needed<br>
<br>
</blockquote>
<br></div>
I think I didn't catch on to that discussion when you had it. Probably because I didn't understand it enough from a brief skim :)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A discussion about such a topic was started here:<br>
<a href="http://marc.info/?l=logback-dev&m=124905434331308&w=2" target="_blank">http://marc.info/?l=logback-dev&m=124905434331308&w=2</a><br>
<<a href="http://marc.info/?l=logback-dev&m=124905434331308&w=2" target="_blank">http://marc.info/?l=logback-dev&m=124905434331308&w=2</a>> but I<br>
completely forgot to file an RFE for it.<br>
I've done just that now, thanks for the reminder!<br>
<a href="http://jira.qos.ch/browse/LBCORE-128" target="_blank">http://jira.qos.ch/browse/LBCORE-128</a><br>
<br>
<br>
I agree with Joern that XMLEncoder is not really suited when throughput is important to you.<br>
</blockquote></div>
For our purpose these "log this complex object" happen rarely enough that we are willing to accept a penalty here, to get a humanly readable rendering.<div class="im"><br></div></blockquote><div><br>It's not about logging complex objects. It's about the number of log events that you can write per second. And the CPU cycles that you waste by generating XML.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
> My current thoughts is to use a ByteArrayOutputStream and<br>
generate a String using the UTF-8 decoding. The resulting string<br>
contains a <?xml ... encoding="UTF-8"?> which is stripped<br>
resulting in an XML String containing Unicode chars (instead of<br>
encoded bytes).<br>
<br>
<br>
What is the difference between "Unicode chars" and "encoded bytes" ?<br>
</blockquote></div>
I am talking about internal representation as char's and the encoded version which is a stream of bytes (which usually is put raw in a file).<div class="im"><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Every unicode codepoint has to be encoded somehow, no ? UTF-8 is one way to encode the codepoint (and imho the encoding everyone should use)<br>
<br>
This can then be flattened to an ASCII version, by converting all<br>
characters outside 32..127 to their numeric entity (&#1234;), and<br>
THAT can be safely logged. I guess :)<br>
><br>
<br>
<br>
If you want to use XML, then I really don't see the problem with leaving it in UTF-8 ?<br>
</blockquote></div>
There is absolutely no guarantee that the final destination of the log string will be able to handle UTF-8 encoded strings. How does UTF-8 encoded strings end up looking when written using MacRoman under OS X?</blockquote>
<div><br>IMHO, you should embrace UTF-8 instead of being afraid of it. Tools that are not able to handle UTF-8 are simply not worth using.<br><br>1) from <a href="http://www.w3.org/TR/xml11/#charencoding">http://www.w3.org/TR/xml11/#charencoding</a>: "<a name="charencoding" id="charencoding">All XML processors <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be able to read entities in both
the UTF-8 and UTF-16 encodings."<br>2) I don't know MacRoman but from http://en.wikipedia.org/wiki/Mac_OS_Roman : "With the release of </a><a href="http://en.wikipedia.org/wiki/Mac_OS_X" title="Mac OS X">Mac OS X</a>, Mac OS Roman was replaced by <a href="http://en.wikipedia.org/wiki/UTF-8" title="UTF-8">UTF-8</a> as the standard character encoding for the Macintosh operating system.<a name="charencoding" id="charencoding">"<br>
<br>regards,<br>Maarten<br><br><br></a></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Especially since you state that "a humanly readable transport format will be preferred." I would prefer to see Σ instead of &#931;<br>
<br>
Of course, it should be possible to tell the XMLEncoder which encoding to use (instead of using the default encoding of the platform).<br>
<br>
</blockquote></div>
XMLEncoder does not have the encoding public. Bah :)<div class="im"><br>
<br>
-- <br>
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"<br>
<br>
_______________________________________________<br></div><div><div></div><div class="h5">
user mailing list<br>
<a href="mailto:user@slf4j.org" target="_blank">user@slf4j.org</a><br>
<a href="http://www.slf4j.org/mailman/listinfo/user" target="_blank">http://www.slf4j.org/mailman/listinfo/user</a></div></div></blockquote></div><br>