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: j o a r <email@hidden>
- Date: Sun, 30 Jan 2005 11:12:30 +0100
On 2005-01-30, at 00.11, 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.
I get this nagging feeling that you're spending a lot of time and
energy on solving a performance problem that you haven't benchmarked
for a solution that's probably not optimal in the first place...
On 2005-01-30, at 06.35, Ken Tozier wrote:
If you read a chunk of data off disk and don't know beforehand what
it's type is, you have to do some sort of test, either of a predefined
code, or a string or something saved with the data and dispatch it
yourself. Originally I was hoping that SELs were fixed in size and
value so that it would be possible to save them as a sort of data
prefix and read them back at a later time something like this
What if you could know the type of the data when you load it from disk,
before peeking at it. Wouldn't that make things easier? Can't you store
data of different types in different places so you know what you're
loading?
If that's not possible, why not store a numerical value representing
the type? After loading a chunk of data you can switch over the
available types to be able to hand the data over to the appropriate
class / method. That should be more efficient both wrt. storage space
and data dispatch.
But, as always, the best suggestion in a case like this one is: Make
something that works first of all. If it doesn't perform as it should,
profile and optimize later!
j o a r
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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