Closed Bug 732815 Opened 13 years ago Closed 11 years ago

Don't re-hash the atom in nsNodeInfoManager::GetNodeInfoInnerHashValue

Categories

(Core :: DOM: Core & HTML, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla28

People

(Reporter: justin.lebar+bug, Assigned: smaug)

References

Details

(Whiteboard: [qa-])

Attachments

(3 files, 2 obsolete files)

nsNodeInfoManager.cpp: >PLHashNumber >nsNodeInfoManager::GetNodeInfoInnerHashValue(const void *key) >{ > NS_ASSERTION(key, "Null key passed to nsNodeInfo::GetHashValue!"); > > const nsINodeInfo::nsNodeInfoInner *node = > reinterpret_cast<const nsINodeInfo::nsNodeInfoInner *>(key); > > if (node->mName) { > return HashString(nsDependentAtomString(node->mName)); > } > return HashString(*(node->mNameString)); >} In bug 729940 comment 23, bz says: > I wish we could use node->mName->hash() [instead of the first call to HashString], but the > mName and mNameString cases need to produce the same hash when they represent the same > string. > > We should consider having nsIAtom::hash() return the HashString of the string instead of what > it returns right now. Followup bug on that, maybe? What nsIAtom::hash() returns right now is described in bug 729940 comment 38: > For my reference, this is kind of complicated right now because atoms store the > pldhashtable's hashcode, which is > > (hash_we_calculate * golden_ratio) >> 1 > > plus some complication if hash_we_calculate * golden_ratio == 0 or 1. The solution would > probably be to store hash_we_calculate in the atom and then do the extra computation on it > when needed.
Attached patch patch (obsolete) — Splinter Review
Not super-pretty, but trying to make sure we don't do any extra hash calculations.
Assignee: nobody → bugs
Attachment #815930 - Flags: review?(bzbarsky)
Comment on attachment 815930 [details] [diff] [review] patch The atom table changes seem really fragile to me, depending on a bunch of implementation details from pldhash, right?
Attached patch v2 (obsolete) — Splinter Review
This way then
Attachment #815930 - Attachment is obsolete: true
Attachment #815930 - Flags: review?(bzbarsky)
Attached patch v3Splinter Review
Attachment #815980 - Attachment is obsolete: true
Attachment #815994 - Flags: review?(bzbarsky)
Attachment #816083 - Flags: review?(bzbarsky)
Attachment #815994 - Flags: review?(bzbarsky)
Comment on attachment 816083 [details] [diff] [review] v4 >+ if (aHash) { >+ mHash = aHash; Could we assert that the string hashes to the right thing in this case? Same in the utf-8 case. r=me with that, and sorry that took so long. :(
Attachment #816083 - Flags: review?(bzbarsky) → review+
Attached patch +assertsSplinter Review
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Whiteboard: [qa-]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: