Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>That code should be fine, but I would suggest a handful of possible changes. These are based on assumptions/observations and may or may not apply.</p> <p>If it is possible, move the uniquing code to a class [factory] method and unique on the value of <code>stuff</code>. That may be pseudo-code, but it would appear that <code>stuff</code> is the sole source of initialization state. Regardless, doing so would save a pass through <code>alloc</code>/<code>dealloc</code> in the collision [cached] case.</p> <p>Assuming nothing else uses <code>UniquingHashTable()</code>, move the <code>static</code> declaration of that = the <code>dispatch_once()</code> initializer into your <code>initWithStuff:</code> (or factory) method. It makes the code clearer and less fragile (in that nothing can muck with the hashtable externally).</p> <p>Use a serial GCD queue for your serialization in the cache lookup code; queues are really cheap and often don't have to cross the user->kernel barrier to enqueue and execute a block.</p> <p>The hashtable will be using a combination of <code>hash</code> and <code>isEqual:</code> to exactly determine object equality (an implementation detail, really... since a weak hashtable uses Object personality, <code>isEqual:</code> will be used as the final say to determine equality). Thus, hash collisions should not be an issue. If you want to ensure that two of your objects with <em>different</em> addresses are not equal, implement your <code>isEqual:</code> accordingly (where two objects that are equal <em>must</em> have the same hash, two inequal objects <em>may</em> have the same hash value).</p> <hr/> <p>The implementation of <code>isEqual:</code> generally first tests pointer equality and, only on failure, does it go down the required rabbit hole of testing internal state to ensure equality.</p> <p>If you have a custom <code>isEqual:</code>, it should do the same.</p> <p>Your code (as originally implemented) is already incurring overhead of a <code>malloc</code> and <code>free</code> (via <code>+alloc</code> and <code>-dealloc</code>) in the collision case. That would be a seemingly huge amount of overhead compared to a few invocations of <code>isEqual:</code> (assuming your hash table isn't hugely collision heavy).</p> <p>How are you measuring the overhead of <code>isEqual:</code> vs. pointer comparison? </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload