On Tue, Dec 1, 2009 at 2:16 AM, Martin Buchholz wrote:
> On Thu, Nov 26, 2009 at 00:57, Goktug Gokdogan wrote:
> > I think, we can overcome the slowdown. The point of my prototype is to
> check
> > the general performance characteristics. Slowdown is more likely due to
> the
> > poorly optimized
On Thu, Nov 26, 2009 at 00:57, Goktug Gokdogan wrote:
> I think, we can overcome the slowdown. The point of my prototype is to check
> the general performance characteristics. Slowdown is more likely due to the
> poorly optimized extra method call to keep all logic in one place. Normally
> the gap
I think, we can overcome the slowdown. The point of my prototype is to check
the general performance characteristics. Slowdown is more likely due to the
poorly optimized extra method call to keep all logic in one place. Normally
the gap buffer algorithm should add only one comparison overhead to th
On Wed, Nov 25, 2009 at 21:24, Martin Buchholz wrote:
> On Mon, Nov 23, 2009 at 22:51, Goktug Gokdogan wrote:
>> Nobody is interested or everybody is busy?
>
> I think there's a place for a StringBuilder-like
> abstraction that uses a gap buffer,
> but it shouldn't replace StringBuilder.
Let me
On Mon, Nov 23, 2009 at 22:51, Goktug Gokdogan wrote:
> Nobody is interested or everybody is busy?
I think there's a place for a StringBuilder-like
abstraction that uses a gap buffer,
but it shouldn't replace StringBuilder.
Like ArrayList, users of StringBuilder
expect that it is very efficient
Actually, this code is not related to size change or management, instead it
modifies where the builder keeps the gap taking into account the last change
position. So I think it is better not to handle these two issues together.
On Tue, Nov 24, 2009 at 4:08 AM, Marek Kozieł wrote:
> 2009/11/17 Gok
2009/11/17 Goktug Gokdogan :
> Hi.
> As you know, java.lang.String classes favor insertion to the end in
> terms of performance. Adding to beginning or middle of these sequences
> causes most of the array to be shifted toward the end every time. Every ones
> in a while I end up changing my algo
Nobody is interested or everybody is busy?
On Tue, Nov 17, 2009 at 3:16 AM, Goktug Gokdogan wrote:
> Hi.
>
> As you know, java.lang.String classes favor insertion to the end in
> terms of performance. Adding to beginning or middle of these sequences
> causes most of the array to be shifted t
Hi Jesús,
I'm sorry for the noise, I just forgot to consider the issues of a
StringBuilder shared between threads (I'm well aware of the JMM etc). A
partial "fix" of sharing only StringBuffer seems useless because we're many
years past JDK1.5 and most code uses StringBuilder now; the tradeoff of
s
Osvaldo Doederlein wrote:
>
> Em 22/11/2009 05:55, Thomas Hawtin escreveu:
>>
>> There is a security issue there. When multiple threads are involved,
>> it is possible (though not necessily easy) to create a mutable String
>> if the backing char[] is shared.
>>
>> Tom Hawtin
>
> That's true. But
Osvaldo Pinali Doederlein wrote:
public String toStringShared() {
// createShared() is a package-protected helper/ctor
String ret = String.createShared(value, 0, count);
// Reset value, so evil user can't abuse the buffer to change
the String.
value = EMPTY;
Em 22/11/2009 05:55, Thomas Hawtin escreveu:
Osvaldo Doederlein wrote:
Looks like good stuff. And it remembers me from another old issue:
patterns of code that demand data copying that could often be
avoided. Every StringBuffer/StringBuilder is ultimately consumed by a
toString() invocation t
> There is a security issue there. When multiple threads are involved, it
> is possible (though not necessily easy) to create a mutable String if
> the backing char[] is shared.
>
> Tom Hawtin
True. I worked in a buffer-sharing / copy-on-write optimization one year
ago, and the main issue was br
Osvaldo Doederlein wrote:
Looks like good stuff. And it remembers me from another old issue:
patterns of code that demand data copying that could often be avoided.
Every StringBuffer/StringBuilder is ultimately consumed by a toString()
invocation to produce the result String, and in 99% of all
2009/11/20 Osvaldo Doederlein :
> Hi Goktug,
>
> Looks like good stuff. And it remembers me from another old issue: patterns
> of code that demand data copying that could often be avoided. Every
> StringBuffer/StringBuilder is ultimately consumed by a toString() invocation
> to produce the result S
Am 20.11.2009 18:30, Osvaldo Doederlein schrieb:
Hi Goktug,
The same problem happens in other buffer-like APIs. In one project I
had to re-implement ByteArrayOutputStream, copying the source code
from the JDK but just adding a method that returns the internal array,
because I was using it for
Hi Goktug,
Looks like good stuff. And it remembers me from another old issue: patterns
of code that demand data copying that could often be avoided. Every
StringBuffer/StringBuilder is ultimately consumed by a toString() invocation
to produce the result String, and in 99% of all uses, only one suc
17 matches
Mail list logo
