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)
Tracking
()
RESOLVED
FIXED
mozilla28
People
(Reporter: justin.lebar+bug, Assigned: smaug)
References
Details
(Whiteboard: [qa-])
Attachments
(3 files, 2 obsolete files)
11.92 KB,
patch
|
Details | Diff | Splinter Review | |
11.94 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
12.66 KB,
patch
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•11 years ago
|
||
Not super-pretty, but trying to make sure we don't do any extra hash calculations.
Assignee: nobody → bugs
Attachment #815930 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 2•11 years ago
|
||
![]() |
||
Comment 3•11 years ago
|
||
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?
Assignee | ||
Comment 4•11 years ago
|
||
This way then
Attachment #815930 -
Attachment is obsolete: true
Attachment #815930 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 5•11 years ago
|
||
Attachment #815980 -
Attachment is obsolete: true
Attachment #815994 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 6•11 years ago
|
||
Just to fix an assert
https://tbpl.mozilla.org/?tree=Try&rev=fd3bcffc8f3a
Assignee | ||
Updated•11 years ago
|
Attachment #816083 -
Flags: review?(bzbarsky)
Assignee | ||
Updated•11 years ago
|
Attachment #815994 -
Flags: review?(bzbarsky)
![]() |
||
Comment 7•11 years ago
|
||
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+
Assignee | ||
Comment 8•11 years ago
|
||
Assignee | ||
Comment 9•11 years ago
|
||
Comment 10•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Updated•11 years ago
|
Whiteboard: [qa-]
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•