Potentially in the future. It has been on a list of candidate enhancements for
quite some time.
As Aleksey just mentioned in his response, (he beat me to the punch), that work
is not in scope as part of this project.
Should also mention that the work from this project would not prohibit such an
On 12/02/2014 04:42 PM, Douglas Surber wrote:
The most common operation on most Strings in query results is to do nothing.
Just construct the String, hold onto it while the rest of the transaction
completes, then drop it on the floor. Probably the next most common is to
encode the chars to wri
The most common operation on most Strings in query results is to do
nothing. Just construct the String, hold onto it while the rest of
the transaction completes, then drop it on the floor. Probably the
next most common is to encode the chars to write them to an
OutputStream or send them back to
On 12/02/2014 03:24 PM, Douglas Surber wrote:
String construction is a big performance issue for JDBC drivers. Most queries
return some number of Strings. The overwhelming majority of those Strings will
be short lived. The cost of constructing these Strings from network bytes is a
large fracti
Hi Douglas,
On 12/03/2014 02:24 AM, Douglas Surber wrote:
> String construction is a big performance issue for JDBC drivers. Most
> queries return some number of Strings. The overwhelming majority of
> those Strings will be short lived. The cost of constructing these
> Strings from network bytes i
String construction is a big performance issue for JDBC drivers. Most
queries return some number of Strings. The overwhelming majority of
those Strings will be short lived. The cost of constructing these
Strings from network bytes is a large fraction of total execution
time. Any increase in the
Hi Vitaly,
Please read the JEP proposal. String/char[] fusion (that's what you are
describing) is out of scope for this work. Baby steps. Careful baby steps.
-Aleksey.
On 03.12.2014 01:13, Vitaly Davidovich wrote:
> Any consideration towards removing the char[] (or byte[]) indirection
> altogeth
Any consideration towards removing the char[] (or byte[]) indirection
altogether? .NET for example stores the bytes inline with the instance.
Sent from my phone
On Dec 2, 2014 4:59 PM, "Aleksey Shipilev"
wrote:
> Hi,
>
> As you may already know, we are looking into more memory efficient
> repres
