I want to cache IMPs in a dictionary for a class that reads many different data types from disk as quickly as possible.
First things first - have you profiled your app to be certain that message-passing is a significant bottleneck?
No, I haven't, still figuring out the best way to write the class in question. The basic idea is to archive a hash code for a method selector (because hash codes are of fixed length while selectors are not) that way, when the data is read back from disk, I could just do a quick lookup of the hash and run the method that is optimized for reading this type of data. This would save lots of disk space (potentially millions of copies of variable length "SEL"s) and the need for huge switch statements to route the data to it's optimized read method.
The address of a selector *is* a hash code. Any two @selector(foo) will be the same address in a given process.
Once it's in memory, yes. But the dilemma was how to store a selector along with the data the selector operates on to disk when the selector itself isn't a fixed length and Apple doesn't guarantee identical hash values for the identical strings between OS releases.
At any rate, I got it working now. I wrote my own hashing function (which I won't change between OS releases),
store the selector strings in an NSDictionary in the "initialize" method, and resolve them as needed with NSSelectorFromString
Thanks for the "swizzling" tips from your previous reply, sparks some interesting ideas...
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden