More memory-efficient internal representation for Strings: call for more data

[Aleksey Shipilev]

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 is a large fraction of total execution time.
> Any increase in the cost of constructing a String will far out weigh any
> reduction in memory use, at least for query results.

You will also have to take into the account that shorter (compressed)
Strings allow for more efficient operations on them. This is not to
mention the GC costs are also usually "hidden" from the naive
performance estimations: even though you can perceive the mutator is
spending more time doing work, that might be offset by easier job for GC.

> All of the proposed compression methods require an additional scan of
> the entire string. That's exactly the wrong direction. Something like
> the following pseudo-code is common inside a driver.
> 
>   {
>     char[] c = new char[n];
>     for (i = 0; i < n; i++) c[i] = charSource.next();
>     return new String(c);
>   }

Good to know. We will be assessing the String(char[]) construction
performance in the course of this performance work. What would you say
is a characteristic high-level benchmark for the scenario you are
describing?

> The array copy inside the String constructor is a significant fraction
> of JDBC driver execution time. Adding an additional scan on top of it is
> making things worse regardless of the transient benefit of more compact
> storage. In the case of a query result the String will be likely never
> be promoted out of new space; the benefit of compression would be minimal.

It's hard to say at this point. We want to understand what footprint
improvements we are talking about. I agree that if cost-benefit analysis
will say the performance is degrading beyond the sane limits even if we
are happy with memory savings, there is little reason to push this into
the general JDK.

Thanks,
-Aleksey