Remove the user-defined empty WTF::String destructor

Remove the user-defined empty WTF::String destructor

Remove the user-defined empty WTF::String destructor:
- It prevents from generating implicitly-declared move/copy
constructors (when C++11 features are enabled).
- Its removal decreases content_shell binary size by 8096 bytes
(linux release build) and slightly simplifies the WTF::String
class declaration.

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=179209

[Mikhail, 2014-07-21 14:31:45]

PTAL.

The commit which had added WTF::String user-defined destructor (r65305) does not
contain any info regarding performance gain obtained with it, so I think we can
rely on blink performance bots to catch the possible regression.

[Inactive, 2014-07-21 14:37:29]

On 2014/07/21 14:31:45, Mikhail wrote:
> PTAL.
> 
> The commit which had added WTF::String user-defined destructor (r65305) does
not
> contain any info regarding performance gain obtained with it, so I think we
can
> rely on blink performance bots to catch the possible regression.

Did you run Dromaeo or similar benchmark to make sure this does not regress
perf?

[Mikhail, 2014-07-25 15:07:49]

On 2014/07/21 14:37:29, Chris Dumez wrote:
> On 2014/07/21 14:31:45, Mikhail wrote:
> > PTAL.
> > 
> > The commit which had added WTF::String user-defined destructor (r65305) does
> not
> > contain any info regarding performance gain obtained with it, so I think we
> can
> > rely on blink performance bots to catch the possible regression.
> 
> Did you run Dromaeo or similar benchmark to make sure this does not regress
> perf?

Sorry for a delay, I have tried Dromaeo DOM tests and some of the Blink
performance tests as well, but I've not observed any noticeable correlation
between this change and the obtained results.

[Mikhail, 2014-07-29 05:41:32]

On 2014/07/25 15:07:49, Mikhail wrote:
> On 2014/07/21 14:37:29, Chris Dumez wrote:
> > On 2014/07/21 14:31:45, Mikhail wrote:
> > > PTAL.
> > > 
> > > The commit which had added WTF::String user-defined destructor (r65305)
does
> > not
> > > contain any info regarding performance gain obtained with it, so I think
we
> > can
> > > rely on blink performance bots to catch the possible regression.
> > 
> > Did you run Dromaeo or similar benchmark to make sure this does not regress
> > perf?
> 
> Sorry for a delay, I have tried Dromaeo DOM tests and some of the Blink
> performance tests as well, but I've not observed any noticeable correlation
> between this change and the obtained results.

Any update here pls? should I try any specific perf tests?

[eseidel, 2014-07-29 15:52:55]

lgtm

Seems worth a try.

[commit-bot: I haz the power, 2014-07-29 15:53:17]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/mikhail.pozdnyakov@intel.com/402193002/1

[commit-bot: I haz the power, 2014-07-29 16:03:47]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  blink_presubmit on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/blink_presubmit/builds/1...)
  win_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/19504)

[commit-bot: I haz the power, 2014-07-29 16:06:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-07-29 16:06:03]

Try jobs failed on following builders:
  win_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/19505)

[Mikhail, 2014-07-30 07:20:34]

The CQ bit was checked by mikhail.pozdnyakov@intel.com

[commit-bot: I haz the power, 2014-07-30 07:22:03]

CQ is trying da patch. Follow status at

https://chromium-status.appspot.com/cq/mikhail.pozdnyakov@intel.com/402193002...

[commit-bot: I haz the power, 2014-07-30 08:33:11]

Change committed as 179209