Bugzilla – Full Text Bug Listing
| Summary: | [evaluator] Improve Tuple's hashCode performance by caching | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Axel Uhl <eclipse> | ||||
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | ed | ||||
| Version: | 3.1.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Axel Uhl
Created attachment 191134 [details]
Caches hashCode of TupleInstance
This patch caches the tuple instance's hash code. A small number of computations is saved during the execution of the test cases which still are all green.
-1. You assume the hashCode cannot be 0 (after numeric truncation). Problem can be fixed by using an Integer rather than an int as the cache. (In reply to comment #2) > -1. You assume the hashCode cannot be 0 (after numeric truncation). > > Problem can be fixed by using an Integer rather than an int as the cache. That was on purpose, actually, because an int comparison is much faster than an Integer comparison, and the likelihood that a half-way reasonably defined hashCode evaluates to 0 is sufficiently small to justify this. However, as the savings are miniscule anyway, I'm happy with closing this as WONTFIX. Feel free... I wasn't thinking of the consequences. If the hashcode really is 0 (1 in 2^32) if uniformly distributed, in practice much less since numeric overflow probably only cuts in after three/four parts, the 0 hash is recomputed and recomputed. No worse than at present. So + 1. Just add a comment to indicate that accidental recomputation is intended and safe. Committed to CVS HEAD, adding a comment as Ed suggested. |