On 3/31/05 10:52 AM, Steve Zellers didst favor us with:
>> On 3/30/05 3:06 PM, steve zellers didst favor us with:
>>
>>> Also, I saw another comment about using GetPtrSize - if at all possible, you
>>> should maintain the size of your allocation if you'll think you'll need it
>>> later. GetPtrSize is rather inefficient.
>>
>> While it's true that the call is less efficient than a lookup, this is
>> not an optimization that is worthwhile unless it's in a very tight loop
>> or other really time intensive/sensitive piece of code.
>>
The next question then, is why isn't the NewPtr mechanism implemented as
efficiently as Steve thinks my substitute would be? If that were the case
then it would be a non-issue. All the code currently using GetPtrSize would
be more efficient and lots of developers could so something more productive
with their time instead of having to worry about this kind of stuff and
changing code. Apple drops the ball again.
>> is (imho) a waste of time to covert your code to malloc/free. Doesn't by you
>> anything except a few nanoseconds per call; instead you could spend
>
> Um, if you multiply those few nanoseconds by the the literally hundreds
> of users of the mac platform, you'll see that there certainly is a
> potential for real CPU savings, worldwide.
And that's really important to all those SETI@Home people who are trying to
detect messages beamed into space from another planet 100 million years ago.
Yes, I think SETI@Home is one of the silliest things I can imagine, but if
you're into it, every cycle counts. ;-)
Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
