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: Ken Tozier <email@hidden>
- Date: Sat, 29 Jan 2005 18:11:15 -0500
On Jan 29, 2005, at 5:37 PM, Sherm Pendley wrote:
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?
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.
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.
Thanks, I'll check it out
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