[
https://issues.apache.org/jira/browse/XERCESJ-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898602#action_12898602
]
Michael Glavassevich commented on XERCESJ-1464:
-----------------------------------------------
I'm sure it was just accidental. At the time this would have been written
SymbolTable was a fixed size (101) so wouldn't have had any impact. We added
rehash later so switching to 31 bits now could improve distribution in a very
large SymbolTable. Thanks for the suggestion.
> SymbolTable.hash uses only 27 bits, when 31 are available
> ---------------------------------------------------------
>
> Key: XERCESJ-1464
> URL: https://issues.apache.org/jira/browse/XERCESJ-1464
> Project: Xerces2-J
> Issue Type: Improvement
> Components: Other
> Affects Versions: 2.10.0
> Environment: any
> Reporter: Roland Illig
> Priority: Minor
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> The hash(...) functions mask out the five most significant bits. The usual
> approach is to only mask out the sign bit.
> This naturally raises the question whether the omission of one F in
> 0x7FF_FFFF was intentional or accidental.
> Even if it is changed to 0x7FFF_FFFF there shouldn't be large performance
> improvements since the distribution of the entries wouldn't be much better
> than now.
> In fact, I'm just curious why you chose 0x7FF_FFFF.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
