26180 2009-06-03 19:19:51 -0700 If "otherOrigin == this" in SecurityOrigin::equal, it's obviously equal. 2009-06-04 11:45:11 -0700 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) All All RESOLVED FIXED P3 Normal --- 1 jorlow webkit-unassigned oldest_to_newest 124264 0 jorlow 2009-06-03 19:19:51 -0700 If "otherOrigin == this" in SecurityOrigin::equal, it's obviously equal. From http://lists.macosforge.org/pipermail/webkit-dev/2009-June/008038.html > SecurityOrigin was created to cleanup the way we do same-origin checks in > the JavaScript bindings, and as such, carry some of that baggage (eg. domain > relaxing). The main design constraint then was that it was a cheap compare > for two origins representing the same document (pointer compare) as that is > common case. The code evolved from there. Makes sense. Note that SecurityOrigin::equal does not currently do a fast path check of "this == other" (to just do a pointer compare as you mentioned) so this is probably low hanging fruit to make things a bit faster. (Though, as you said, it's not showing up on current profiles...so it's probably not a huge deal.) 124266 1 30937 jorlow 2009-06-03 19:27:42 -0700 Created attachment 30937 A fix. 124267 2 sam 2009-06-03 19:42:29 -0700 Wouldn't it makes more sense to do this in isSameSchemeHostPort? 124270 3 jorlow 2009-06-03 20:23:38 -0700 I don't think so. I only see isSameSchemeHostPort used a couple places, but they don't seem like they'd benefit from such an optimization [1]. ::equal, on the other hand, is called pretty often (it's used a lot in hash tables). It seems a bit painful to require another function call plus a branch or two for a function that's not called very often. We could put the == check in both places. Doing one additional branch isn't going to hurt the slow path. It doesn't seem necessary though. [1] http://www.google.com/codesearch?hl=en&q=isSameSchemeHostPort+package%3A%22git%3A%2F%2Fandroid.git.kernel.org%2Fplatform%2Fexternal%2Fwebkit.git%22 124314 4 30937 darin 2009-06-04 09:18:59 -0700 Comment on attachment 30937 A fix. Seems fine. r=me 124340 5 bfulgham 2009-06-04 11:10:54 -0700 Assign for landing. 124344 6 bfulgham 2009-06-04 11:34:50 -0700 Landed in @r44420. 30937 2009-06-03 19:27:42 -0700 2009-06-04 09:18:59 -0700 A fix. fast_path.patch text/plain 1170 jorlow SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0NDQwNikKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTUgQEAKKzIwMDktMDYtMDMgIEplcmVteSBPcmxvdyAgPGpvcmxvd0BjaHJvbWl1 bS5vcmc+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAg aHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTI2MTgwCisgICAgICAgIEFk ZCBhIGZhc3QgcGF0aCBmb3IgU2VjdXJpdHlPcmlnaW46OmVxdWFsLiBJZiAib3RoZXIgPT0gdGhp cyIgKHdoZXJlCisgICAgICAgIG90aGVyIGlzIHRoZSBvdGhlciBzZWN1cml0eSBvcmlnaW4pLCB0 aGVuIHdlIHJlYWxseSBkb24ndCBuZWVkIHRvIGRvCisgICAgICAgIGFsbCB0aGUgb3RoZXIgKGV4 cGVuc2l2ZSkgY29tcGFyaXNvbnMuIFdlIGtub3cgaXQncyBlcXVhbC4KKworICAgICAgICAqIHBh Z2UvU2VjdXJpdHlPcmlnaW4uY3BwOgorICAgICAgICAoV2ViQ29yZTo6U2VjdXJpdHlPcmlnaW46 OmVxdWFsKToKKwogMjAwOS0wNi0wMyAgRGFuIEJlcm5zdGVpbiAgPG1pdHpAYXBwbGUuY29tPgog CiAgICAgICAgIC0gV2luZG93cyBidWlsZCBmaXgKSW5kZXg6IFdlYkNvcmUvcGFnZS9TZWN1cml0 eU9yaWdpbi5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9wYWdlL1NlY3VyaXR5T3JpZ2luLmNw cAkocmV2aXNpb24gNDQ0MDUpCisrKyBXZWJDb3JlL3BhZ2UvU2VjdXJpdHlPcmlnaW4uY3BwCSh3 b3JraW5nIGNvcHkpCkBAIC0yNzcsNiArMjc3LDkgQEAgU3RyaW5nIFNlY3VyaXR5T3JpZ2luOjpk YXRhYmFzZUlkZW50aWZpZQogCiBib29sIFNlY3VyaXR5T3JpZ2luOjplcXVhbChjb25zdCBTZWN1 cml0eU9yaWdpbiogb3RoZXIpIGNvbnN0IAogeworICAgIGlmIChvdGhlciA9PSB0aGlzKQorICAg ICAgICByZXR1cm4gdHJ1ZTsKKyAgICAKICAgICBpZiAoIWlzU2FtZVNjaGVtZUhvc3RQb3J0KG90 aGVyKSkKICAgICAgICAgcmV0dXJuIGZhbHNlOwog