Thanks Peter, this is a nice improvement. I’ll incorporate your changes before
pushing.
-Chris.
On 5 Feb 2014, at 16:39, Peter Levart peter.lev...@gmail.com wrote:
On 02/05/2014 04:11 PM, Chris Hegarty wrote:
Thanks stuart, Mike, and Paul.
- Why not have getClassSignature() return an
Hi,
I looked into the UTF serialization and deserialization code - and compared it
a bit with the code behind new String(byte[], Charset),
String.getBytes(Charset).
Just to find something that can be safely reused in Object*Stream classes to
optimize String handling.
The first thing I noticed
Modified UTF8 has to be used, as specified by the spec.
http://download.java.net/jdk8/docs/api/java/io/DataInput.html#modified-utf-8
-Sherman
On 02/06/2014 02:50 PM, Robert Stupp wrote:
-Chris.
eh - yes - ouch! 21 bit cannot occur (char = 16 bits)
please, please ignore my comment about it.
Am 07.02.2014 um 00:15 schrieb Xueming Shen xueming.s...@oracle.com:
Modified UTF8 has to be used, as specified by the spec.
Thanks stuart, Mike, and Paul.
- Why not have getClassSignature() return an interned string? (that's if
interning is actually essential. Are we sure it's not just overhead?)
I didn’t want to change the existing use of interning here, just refactor the
code a little to make it cleaner.
I
On 02/05/2014 04:11 PM, Chris Hegarty wrote:
Thanks stuart, Mike, and Paul.
- Why not have getClassSignature() return an interned string? (that's if
interning is actually essential. Are we sure it's not just overhead?)
I didn’t want to change the existing use of interning here, just refactor
On Feb 3, 2014, at 11:01 PM, Stuart Marks stuart.ma...@oracle.com wrote:
Nobody took the bait on this yet? :-)
Certainly there's a lot of semi-myth on this topic, on both sides. Here's my
source of mythology (or urban legend, as one might have it):
Nobody took the bait on this yet? :-)
Certainly there's a lot of semi-myth on this topic, on both sides. Here's my
source of mythology (or urban legend, as one might have it):
http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html
My concern here is not so much about leaking of
();
-}
}
*Gesendet:* Dienstag, 07. Januar 2014 um 10:05 Uhr
*Von:* Chris Hegarty chris.hega...@oracle.com
*An:* Robert Stupp sn...@gmx.de
*Cc:* core-libs-dev@openjdk.java.net Libs core-libs-dev@openjdk.java.net
*Betreff:* Re: ObjectIn/OutputStream improvements
On 15 Dec 2013, at 10:29, Robert
: Freitag, 31. Januar 2014 um 15:22 Uhr
Von: Chris Hegarty chris.hega...@oracle.com
An: Robert Stupp sn...@gmx.de, core-libs-dev-request
core-libs-dev-requ...@openjdk.java.net
Betreff: Re: Aw: Re: ObjectIn/OutputStream improvements
Hi Robert,
I think your patch can be split into two logical
On 1/31/14 10:46 AM, Chris Hegarty wrote:
I think your patch can be split into two logical, independent, parts. The
first is the use of unsafe to access the String UTF length. The seconds is
to reuse, where possible, the existing StringBuilder instances, skipping of
primitive/object
On 31 Jan 2014, at 19:07, Stuart Marks stuart.ma...@oracle.com wrote:
On 1/31/14 10:46 AM, Chris Hegarty wrote:
I think your patch can be split into two logical, independent, parts. The
first is the use of unsafe to access the String UTF length. The seconds is
to reuse, where possible, the
*Betreff:* Re: ObjectIn/OutputStream improvements
On 15 Dec 2013, at 10:29, Robert Stupp sn...@gmx.de wrote:
Hi,
I digged through the object serialization code and found some lines
that could be optimized to reduce the number of calls to
System.arraycopy() and temporary object allocations
One would have to measure of course, but intuitively, it seems like a good
change to reuse the stringbuilder. There's also the issue that the local
stringbuilder before was default-sized, and for large content, it would
generate even more garbage as the underlying array is expanded.
The
I found another location in OOS code that might be an optimization point:
In java.io.ObjectOutputStream.BlockDataOutputStream#write(byte[], int, int,
boolean) the first lines look like this:
if (!(copy || blkmode)) { // write directly
drain();
On 15 Dec 2013, at 10:29, Robert Stupp sn...@gmx.de wrote:
Hi,
I digged through the object serialization code and found some lines that
could be optimized to reduce the number of calls to System.arraycopy() and
temporary object allocations especially during string (de)serialization.
In
16 matches
Mail list logo
