On Sep 4, 2012, at 5:52 PM, Benjamin Poulain wrote:
> On Tue, Sep 4, 2012 at 4:22 PM, Adam Barth wrote:
> Removing operator+= will likely require changes to a number of
> port-specific files. I'll do my best to remove these, but I might
> need some help from maintainers of individual ports. I
On Wed, Sep 5, 2012 at 12:44 PM, Adam Barth wrote:
> On Wed, Sep 5, 2012 at 3:23 AM, Patrick Gansterer wrote:
>> On Tue, 04 Sep 2012 22:26:52 -0700, Adam Barth wrote:
>>>
>>> On Tue, Sep 4, 2012 at 10:06 PM, Christophe Dumez
>>> wrote:
On Sep 5, 2012, at 2:22 AM, Adam Barth wrote:
>>>
On Wed, Sep 5, 2012 at 3:23 AM, Patrick Gansterer wrote:
> On Tue, 04 Sep 2012 22:26:52 -0700, Adam Barth wrote:
>>
>> On Tue, Sep 4, 2012 at 10:06 PM, Christophe Dumez
>> wrote:
>>>
>>> On Sep 5, 2012, at 2:22 AM, Adam Barth wrote:
Removing operator+= will likely require changes to a
On Tue, 04 Sep 2012 22:26:52 -0700, Adam Barth wrote:
On Tue, Sep 4, 2012 at 10:06 PM, Christophe Dumez
wrote:
On Sep 5, 2012, at 2:22 AM, Adam Barth wrote:
Removing operator+= will likely require changes to a number of
port-specific files. I'll do my best to remove these, but I might
need s
On Tue, Sep 4, 2012 at 10:06 PM, Christophe Dumez
wrote:
> On Sep 5, 2012, at 2:22 AM, Adam Barth wrote:
>> Removing operator+= will likely require changes to a number of
>> port-specific files. I'll do my best to remove these, but I might
>> need some help from maintainers of individual ports.
On Sep 5, 2012, at 2:22 AM, Adam Barth wrote:
> Removing operator+= will likely require changes to a number of
> port-specific files. I'll do my best to remove these, but I might
> need some help from maintainers of individual ports. If you're
> interested in helping out, please let me know.
On Tue, Sep 4, 2012 at 4:22 PM, Adam Barth wrote:
> Removing operator+= will likely require changes to a number of
> port-specific files. I'll do my best to remove these, but I might
> need some help from maintainers of individual ports. If you're
> interested in helping out, please let me know
>
>
> If operator+= cannot be made sufficiently efficient, we could always leave
> the operator there, but have it ASSERT with a message saying to use
> StringBuilder.
>
>
> Please not this. Failing at compile time is much better than failing at
> runtime in debug builds only.
>
> I was only half s
On Sep 4, 2012, at 5:16 PM, Mike Lawther wrote:
> On 5 September 2012 09:44, Dirk Schulze wrote:
> It is very likely that even future code will land with this operator instead
> of StringBuilder.
>
> Not if Adam removes the operator as he proposed earlier :)
>
> If operator+= cannot be made
On 5 September 2012 09:44, Dirk Schulze wrote:
> It is very likely that even future code will land with this operator
> instead of StringBuilder.
Not if Adam removes the operator as he proposed earlier :)
If operator+= cannot be made sufficiently efficient, we could always leave
the operator
On Sep 4, 2012, at 4:44 PM, Dirk Schulze wrote:
> Yes, looks like the efforts didn't went further. Anyway, is there no
> possibility to improve operator+= further? It is very likely that even future
> code will land with this operator instead of StringBuilder. I think it is
> better to try to
operator+ is now efficient (potentially more so than using a StringBuilder if
you can do it all in one statement). operator+= still sucks, and I don't think
we came up with an obvious way to get good performance with the same syntax.
One possibility: we could add operator+=(String&) to StringBu
Yes, looks like the efforts didn't went further. Anyway, is there no
possibility to improve operator+= further? It is very likely that even future
code will land with this operator instead of StringBuilder. I think it is
better to try to change the operator (if possible) instead of people.
Gree
Ah, you're think of operator+, which is now quite efficient. This
thread is about operator+=, which is sadly slower than molasses.
Adam
On Tue, Sep 4, 2012 at 4:38 PM, Dirk Schulze wrote:
> With a short search in the logs I found optimizations for at least
> operator+, but didn't search furt
With a short search in the logs I found optimizations for at least operator+,
but didn't search further:
http://trac.webkit.org/changeset/86330
https://bugs.webkit.org/show_bug.cgi?id=58420
Greetings,
Dirk
On Sep 4, 2012, at 4:31 PM, Adam Barth wrote:
> Do you have a proposal for how that wo
Do you have a proposal for how that would work and/or a link to the
previous discussion?
Adam
On Tue, Sep 4, 2012 at 4:27 PM, Dirk Schulze wrote:
> I thought we had efforts to make String::operator+= use StringBuilder
> somehow? I can remember that we had a discussion on webkit-dev and definit
I thought we had efforts to make String::operator+= use StringBuilder somehow?
I can remember that we had a discussion on webkit-dev and definitely on
bugzilla about improving String::operator+= instead of replacing it with
StringBuilder.
Greetings,
Dirk
On Sep 4, 2012, at 4:22 PM, Adam Barth
As part of the work to deploy efficient string patterns [1] throughout
WebKit, Benjamin and I noticed a bunch of very inefficient code that
uses operator+= with Strings:
String foo;
for (...)
foo += [...];
return foo;
This pattern is particularly inefficient because += mallocs an
entirely new b
18 matches
Mail list logo
