views:

71

answers:

2

Hi,

when I register a large number (10000+) of additional selectors in an Objective-C program using the runtime function sel_registerName, does this slow down my program? Not taking into account the time it takes to register those selectors.

Best regards, Jochen

+1  A: 

No, but each selector would have to be resident in memory and can't be unregistered. This will reduce the amount of RAM available for the rest of your application.

rpetrich
+4  A: 

It will only slow down your application if you are creating an extremely pathologically named set of selectors that just so happen to all stack up in one bucket in the hash of selectors within Objective-C's method cache.

Very unlikely. If you are seeing a performance issue, measure it with Instruments (or some other tool) and determine where it is before trying to optimize.

While rpetrich's answer is correct, the amount of RAM per selector is minimal. In terms of the selector itself, it'll just be an address's worth of data. The actual selector value is not typically used. If the selectors are composed of statically allocated strings, it is unlikely that anything will actually touch the memory (unless your code does).

If you are dynamically generating the selector names, then the allocations will, obviously, take up memory.

(I am, of course, quite thoroughly curious why you are generating so many selectors. Quite the atypical pattern!)

bbum
I have to manage a large set of IDs, with two specific issues: First, the set of needed IDs and the set of selectors present in my program code overlap. Second, the IDs need to be mapped to integers. So I thought I'd let the runtime do the job...
Jochen
An alternative would be to simply define a single selector that returns the ID and then implement said selector wherever needed. If the selector is the ID, then the act of creating the selector would seem to be enough to create the ID? From my point of ignorance, it still seems odd. :)
bbum