RenderFrameImpl: avoid creating many temporary WebDocuments.

RenderFrameImpl: avoid creating many temporary WebDocuments.

Accessing a property off of a WebFrame's document will entail instantiating
a WebDocument, which implies a WebPrivatePtr<> holding a persistent reference.

Avoid the overhead via some manual CSEing.

R=esprehn,jochen
BUG=

Review-Url: https://codereview.chromium.org/2723083002
Cr-Commit-Position: refs/heads/master@{#454878}
Committed: https://chromium.googlesource.com/chromium/src/+/ad341188a500e8641b96f48ab644a691912f982e

[sof, 2017-03-01 12:34:28]

The CQ bit was checked by sigbjornf@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2017-03-01 12:34:43]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[sof, 2017-03-01 12:43:26]

sigbjornf@opera.com changed reviewers:
+ esprehn@chromium.org, jochen@chromium.org

[sof, 2017-03-01 12:43:26]

please take a look.

while examining Persistent<> allocation patterns, I noticed we're churning
through 4-5 persistents per request. Worth avoiding?

[commit-bot: I haz the power, 2017-03-01 13:40:27]

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

[commit-bot: I haz the power, 2017-03-01 13:40:30]

Dry run: This issue passed the CQ dry run.

[esprehn, 2017-03-03 21:51:21]

lgtm, but someone will likely refactor this the other way eventually. We should
work on moving all of this code into blink itself so we can remove the
Persistent<> wrapper.

I do wonder how often WebNode and friends are actually stored not on the stack
and we if could make them store a raw ptr instead, I guess that means
std::vector<WebNode> becomes invalid and you'd need to do stuff like
std::vector<WebHandle<WebNode>>.

[esprehn, 2017-03-03 21:59:01]

Actually doesn't allocatePersistentNode and freePersistentNode have a free list
where we'd reuse the same Persistent repeatedly?

[sof, 2017-03-03 22:04:55]

On 2017/03/03 21:59:01, esprehn wrote:
> Actually doesn't allocatePersistentNode and freePersistentNode have a free
list
> where we'd reuse the same Persistent repeatedly?

Yes, the same PersistentNode will be reused for each Persistent<> allocated and
initialized..and then cleared & uninitialized just after.

[jochen (gone - plz use gerrit), 2017-03-06 12:51:57]

lgtm

[sof, 2017-03-06 16:16:26]

Description was changed from

==========
RenderFrameImpl: avoid creating many temporary WebDocuments.

Accessing a property off of a WebFrame's document will entail instantiating
a WebDocument, which implies a WebPrivatePtr<> holding a persistent reference.

Avoid the overhead via some manual CSEing.

R=
BUG=
==========

to

==========
RenderFrameImpl: avoid creating many temporary WebDocuments.

Accessing a property off of a WebFrame's document will entail instantiating
a WebDocument, which implies a WebPrivatePtr<> holding a persistent reference.

Avoid the overhead via some manual CSEing.

R=esprehn,jochen
BUG=
==========

[sof, 2017-03-06 16:16:30]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2017-03-06 16:17:00]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-06 17:03:55]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1488816990474140, "parent_rev":
"87a17804ec5928ea8f3def2e7ddc7d262f5007c4", "commit_rev":
"ad341188a500e8641b96f48ab644a691912f982e"}

[commit-bot: I haz the power, 2017-03-06 17:04:29]

Description was changed from

==========
RenderFrameImpl: avoid creating many temporary WebDocuments.

Accessing a property off of a WebFrame's document will entail instantiating
a WebDocument, which implies a WebPrivatePtr<> holding a persistent reference.

Avoid the overhead via some manual CSEing.

R=esprehn,jochen
BUG=
==========

to

==========
RenderFrameImpl: avoid creating many temporary WebDocuments.

Accessing a property off of a WebFrame's document will entail instantiating
a WebDocument, which implies a WebPrivatePtr<> holding a persistent reference.

Avoid the overhead via some manual CSEing.

R=esprehn,jochen
BUG=

Review-Url: https://codereview.chromium.org/2723083002
Cr-Commit-Position: refs/heads/master@{#454878}
Committed:
https://chromium.googlesource.com/chromium/src/+/ad341188a500e8641b96f48ab644...
==========

[commit-bot: I haz the power, 2017-03-06 17:04:30]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/ad341188a500e8641b96f48ab644...