Re: Do IMPs move once they're loaded?
Re: Do IMPs move once they're loaded?
- Subject: Re: Do IMPs move once they're loaded?
- From: Sherm Pendley <email@hidden>
- Date: Sat, 29 Jan 2005 17:37:53 -0500
On Jan 29, 2005, at 5:08 PM, Ken Tozier wrote:
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? Or are you just guessing
that it might be? Premature optimization is the root of all evil, as
the saying goes...
One reason I'm asking is that you're reinventing a wheel with this.
Apple's runtime does pretty much exactly what you're trying to do,
cacheing IMPs to avoid redundant SEL lookups for frequently-called
methods - but it's in a position to do so safely. It is aware of each
and every change to class definitions, and avoids the question of stale
IMPs by flushing its caches when necessary.
I haven't actually tested the above so it probably won't work as
written, but the primary question is if the system moves "IMP"
function pointers around at runtime.
Apple's libobjc is available as part of Darwin, so you could look there
for an authoritative answer if you want.
For my part, I'd be not so concerned about IMPs moving, but by them
being replaced. Category methods are documented as replacing any
duplicate methods found in the base class definition. Like I said
above, Apple's runtime knows when class definitions change, and flushes
its caches accordingly when needed.
Your code isn't in such a privileged position. You could register to be
notified whenever NSBundle is used to load new code, but that would
still leave CFBundle and dlopen() to worry about - not to mention calls
to objc_addMethods().
With all of the ways an IMP could change behind your back, it's not
very safe to cache them long-term. They're meant to be used sparingly,
and only within very tight loops where there's no possibility of
runtime changes happening.
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
_______________________________________________
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