«

String value="";
if(value.length() == 0) {
char data[]=new char[count];
for(int c=0;c<count;c++){
data[c]='0';
}
value=new String(data);

wrote:
> String value="";
> if(value.length() == 0) {
> char data[]=new char[count];
> for(int c=0;c<count;c++){
> data[c]='0';
> }
> value=new String(data);

Why do you want to optimize this code? Have you profiled to make sure
that it is these lines specifically that are the bottleneck?

If speed really is an issue, then the only thing that jumps out at me
for optimizing is getting rid of the for loop:

java.util.Arrays.fill(data, '0');

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Joshua Cranmer wrote:
> wrote:
>> String value="";
>> if(value.length() == 0) {
>> char data[]=new char[count];
>> for(int c=0;c<count;c++){
>> data[c]='0';
>> }
>> value=new String(data);
>
> Why do you want to optimize this code? Have you profiled to make sure
> that it is these lines specifically that are the bottleneck?
>
> If speed really is an issue, then the only thing that jumps out at me
> for optimizing is getting rid of the for loop:
>
> java.util.Arrays.fill(data, '0');

Is that faster? Enough faster?

--
Lew

(It's considered polite to put your question in the body
of the message, even if it also appears as the Subject.)

wrote:
> String value="";
> if(value.length() == 0) {
> char data[]=new char[count];
> for(int c=0;c<count;c++){
> data[c]='0';
> }
> value=new String(data);

Well, let's see. The original assignment to `value'
is a waste of time, as is the `if'. Also, `new String(data)'
will create its own private copy of the `data' array -- it
must do so, or else you could change the value of the String
by changing `data' after the String is constructed, so you
might be better off using a StringBuilder. All in all:

StringBuilder data = new StringBuilder(count);
for (int c = 0; c < count; ++c)
data.append('0');
String value = data.toString();

.... and it's hard to believe this would make enough of a
difference to be worth worrying about.

--

Lew wrote:
> Joshua Cranmer wrote:
>> wrote:
>>> String value="";
>>> if(value.length() == 0) {
>>> char data[]=new char[count];
>>> for(int c=0;c<count;c++){
>>> data[c]='0';
>>> }
>>> value=new String(data);
>>
>> Why do you want to optimize this code? Have you profiled to make sure
>> that it is these lines specifically that are the bottleneck?
>>
>> If speed really is an issue, then the only thing that jumps out at me
>> for optimizing is getting rid of the for loop:
>>
>> java.util.Arrays.fill(data, '0');
>
> Is that faster? Enough faster?
>

It may be faster, depending on the system. The only way to tell if it is
enough faster is for the OP to measure it.

Many systems have a very fast way of pushing a repeated bit pattern to
an area of memory. For example, on Sun SPARC systems, 64 byte chunks of
memory can be written from the floating point registers.

If the OP's system has some such facility, and Arrays.fill is
implemented on that system as a native method using an optimized memory
write method, then it may be significantly faster than than writing one
char at a time.

Patricia

Patricia Shanahan wrote:
> Lew wrote:
>> Joshua Cranmer wrote:
>>> wrote:
>>>> String value="";
>>>> if(value.length() == 0) {
>>>> char data[]=new char[count];
>>>> for(int c=0;c<count;c++){
>>>> data[c]='0';
>>>> }
>>>> value=new String(data);
>>>
>>> Why do you want to optimize this code? Have you profiled to make sure
>>> that it is these lines specifically that are the bottleneck?
>>>
>>> If speed really is an issue, then the only thing that jumps out at me
>>> for optimizing is getting rid of the for loop:
>>>
>>> java.util.Arrays.fill(data, '0');
>>
>> Is that faster? Enough faster?
>>
>
> It may be faster, depending on the system. The only way to tell if it is
> enough faster is for the OP to measure it.
>
> Many systems have a very fast way of pushing a repeated bit pattern to
> an area of memory. For example, on Sun SPARC systems, 64 byte chunks of
> memory can be written from the floating point registers.
>
> If the OP's system has some such facility, and Arrays.fill is
> implemented on that system as a native method using an optimized memory
> write method, then it may be significantly faster than than writing one
> char at a time.

You right. However, the reference implementation of Arrays.fill() (I
mean the one from the Sun) is implemented as a simple loop filling an
array slot by slot.

A few years ago I wrote an alternative version of the array fill based
on System.arraycopy(), which without an extra optimizations normally
performed by the server JVM is even 5 times faster (sometimes more) than
the original Arrays.fill() implementation. (The server JVM usually
still executes it faster, but it's not as significant as in a case of
the client JVM -- typically not faster than 2 times.)

The original algorithm is there:
<http://groups.google.com/group/pl.comp.lang.java/msg/99526c39faf0338c?>
The thread includes also a performance test driver, and some test
results. (Sorry, the thread is in Polish. But at least the code should
be clear for everyone, I hope...)


piotr

Eric Sosman wrote:

> Also, `new String(data)'
> will create its own private copy of the `data' array -- it
> must do so, or else you could change the value of the String
> by changing `data' after the String is constructed, so you
> might be better off using a StringBuilder. All in all:
>
> StringBuilder data = new StringBuilder(count);
> for (int c = 0; c < count; ++c)
> data.append('0');
> String value = data.toString();

Is there any benefit of doing it that way?

There is also a private copy of data array created by the String in this
case.

Here is, for example, the StringBuilder's toString() implementation from
the Sun JDK 1.6:

public String toString() {
// Create a copy, don't share the array
return new String(value, 0, count);
}

A data sharing between String and StringBuffer (AFAIK never supported by
StringBuiledr) was ceased starting Java 1.5.


piotr

wrote:
> String value="";
> if(value.length() == 0) {
> char data[]=new char[count];
> for(int c=0;c<count;c++){
> data[c]='0';
> }
> value=new String(data);

If there is a (small) limit on the maximum value of count, then

value = "0000000000000000000000000000000000000000".substri ng(0, count);

may be an alternative.

Arne

Piotr Kobzda wrote:
> Eric Sosman wrote:
>
>> Also, `new String(data)'
>> will create its own private copy of the `data' array -- it
>> must do so, or else you could change the value of the String
>> by changing `data' after the String is constructed, so you
>> might be better off using a StringBuilder. [...]
>
> A data sharing between String and StringBuffer (AFAIK never supported by
> StringBuiledr) was ceased starting Java 1.5.

I wasn't aware of that; thanks for the information.

I'm still of the opinion, though, that the code fragment
is almost certainly not worth optimizing.

--
Eric Sosman
lid

Piotr Kobzda <> writes:
>A data sharing between String and StringBuffer (AFAIK never
>supported by StringBuiledr) was ceased starting Java 1.5.

According to Web sources »StringBuilder« is slightly
faster than »StringBuffer«, because it does not include
synchronization.

Sun Microsystems, Inc. claims:

»StringBuilder is almost always faster than StringBuffer.«

http://java.sun.com/j2se/1.5.0/docs/...nce/speed.html

I try to use »java.lang.CharSequence« for text results and
text parameter types instead of »java.lang.String«, so that
the »toString()« operation only needs to be invoked when a
string really is required.