Avoid initializing a SecurityOrigin from a KURL for isSecure() check.

Avoid initializing a SecurityOrigin from a KURL for isSecure() check.

Initializing a SecurityOrigin is not cheap. We should avoid it where possible.

Initialization causes
 - Looking up the origin in a map (blobs)
 - FastMalloc the origin
 - Many calls to StringImpl::lower() which causes allocation
 - HashMap lookups for e.g. shouldTreatURLSchemeAsLocal

This saves ~1% overhead off of resource requesting.

BUG=348655
Committed: https://crrev.com/616c7df79bbc2d892ecee0305dff57a0faaf80a2
Cr-Commit-Position: refs/heads/master@{#425946}

[Charlie Harrison, 2016-10-13 17:32:29]

The CQ bit was checked by csharrison@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-13 17:32:49]

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

[Charlie Harrison, 2016-10-13 17:34:22]

csharrison@chromium.org changed reviewers:
+ mkwst@chromium.org

[Charlie Harrison, 2016-10-13 17:34:22]

Hi Mike,
Apologies for the CL bombardment. This one is a bit strange as it adds an API
for URL trustworthiness rather than Origin. Let me know if you think it is too
ugly.

[Charlie Harrison, 2016-10-13 17:38:38]

Note: if this CL and the other one checking for whitelisted trustworthiness
land, the only overhead (I can tell) left in mixed content blocking is HashMap
lookups.

[commit-bot: I haz the power, 2016-10-13 20:13:02]

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

[commit-bot: I haz the power, 2016-10-13 20:13:03]

Dry run: This issue passed the CQ dry run.

[Mike West, 2016-10-18 10:03:13]

On 2016/10/13 at 17:34:22, csharrison wrote:
> Hi Mike,
> Apologies for the CL bombardment. This one is a bit strange as it adds an API
for URL trustworthiness rather than Origin. Let me know if you think it is too
ugly.

It's a bit ugly, but no uglier than the existing code. Perhaps we could hide the
ugliness by not making it a public method, but instead a static function inside
`Source/platform/weborigin/SecurityOrigin.cpp`? I guess that would require us to
expose the static list of trustworthy origins. *shrug* No real benefit.

LGTM either way.

[Charlie Harrison, 2016-10-18 12:21:40]

Yeah I came to the same conclusion. We could also expose a bool member
"hasWhitelistedOrigins" which does the empty check. I wasn't too enthused with
that.

[Charlie Harrison, 2016-10-18 12:22:09]

The CQ bit was checked by csharrison@chromium.org

[commit-bot: I haz the power, 2016-10-18 12:22:28]

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, 2016-10-18 13:46:19]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-10-18 13:48:24]

Description was changed from

==========
Avoid initializing a SecurityOrigin from a KURL for isSecure() check.

Initializing a SecurityOrigin is not cheap. We should avoid it where possible.

Initialization causes
 - Looking up the origin in a map (blobs)
 - FastMalloc the origin
 - Many calls to StringImpl::lower() which causes allocation
 - HashMap lookups for e.g. shouldTreatURLSchemeAsLocal

This saves ~1% overhead off of resource requesting.

BUG=348655
==========

to

==========
Avoid initializing a SecurityOrigin from a KURL for isSecure() check.

Initializing a SecurityOrigin is not cheap. We should avoid it where possible.

Initialization causes
 - Looking up the origin in a map (blobs)
 - FastMalloc the origin
 - Many calls to StringImpl::lower() which causes allocation
 - HashMap lookups for e.g. shouldTreatURLSchemeAsLocal

This saves ~1% overhead off of resource requesting.

BUG=348655

Committed: https://crrev.com/616c7df79bbc2d892ecee0305dff57a0faaf80a2
Cr-Commit-Position: refs/heads/master@{#425946}
==========

[commit-bot: I haz the power, 2016-10-18 13:48:25]

Patchset 1 (id:??) landed as
https://crrev.com/616c7df79bbc2d892ecee0305dff57a0faaf80a2
Cr-Commit-Position: refs/heads/master@{#425946}