On 10/30/05 1:28 AM, Lawrence Sanbourne didst favor us with:
>> A few thoughts:
>>
>> - The CFArray approach doesn't seem very efficient since for each directory
>> you add to the array you have to create a CFDataRef, and then later in the
>> same function reverse the process by calling CFDataGetBytes.
>
> This is my way of copying the FSRefs. I have to copy them instead of
> storing their memory addresses because they are in the array, which I
> keep reusing during the loop. This was the cause of the error I wrote
> to carbon-dev about originally.
I had a feeling it might be something like that, which is why I originally
suggested using something that didn't involve CF.
>> - I use a different logic that doesn't use recursion. I run through a
>> folder, using a stack to store folders as I encounter them. When I complete
>> the current folder I pop the last folder off the stack, make it the current
>> folder and loop around again. I only allocate FSRef and FSCatalogInfo
>> buffers once and just keep reusing them.
>>
>> The stack I use to store folders (which is an STL vector but used to be the
>> FSRefHandle I described in another post)
>
> Is the STL faster than the Core Foundation collections?
Are CF arrays faster than STL vectors?
> You seem to assume this, but there's definitely no reason why it would have to
> be.
And vice versa.
> The STL is software, just as Core Foundation is.
True, but what evidence do you have that CF is faster? In any case, don't
get fixated on STL. If you don't like or want to use STL, that's fine. It
would be simple enough to write code for an efficient stack that would do
the same thing. You're just storing a bunch of 80-byte structs. Nothing is
going to be more efficient than copying them to or reading from slots in an
array.
My code:
folderStack.push_back( fsRefArray[ idx ] );
Your code:
CFDataRef resultRefData = CFDataCreate(kCFAllocatorDefault, (const UInt8
*)&resultRefs[i], sizeof(resultRefs[i]));
CFArrayAppendValue(subDirectoryPaths, resultRefData);
CFRelease(resultRefData);
Your code is creating a CFDataRef for each folder it adds to the array,
which is a memory allocation. CF is doing whatever it does to create a
CFDataRef from an FSRef. Then you append to a CFArray (which could trigger a
reallocation to increase the capacity of the array) and decrement the retain
count on the dataRef. What are the chances all that is faster than a
vector.push_back()?
When I need the next one, I do this:
err = fsIterator.OpenFlat( folderStack.back() );
folderStack.pop_back();
Your code has to call CFArrayGetValueAtIndex() to retrieve a CFDataRef, call
CFDataGetLength() to get the size of the data, and finally CFDataGetBytes()
to get the FSRef. Oh, and an inline CFRangeMake to create a CFRange. What
are the chances all that is faster than the simple stack approach?
Performance aside, the stack approach (STL or one you write yourself) is
cleaner and simpler than all these CF calls and casting.
> Well, this is definitely quite nice, and avoiding all the memory
> allocations will be a big help. I will change my implementation when I
> next get time. Or you're welcome to do it -- it's open source code.
> :-) However, if you do decide to implement this, please don't switch
> to the STL unless it's definitely faster.
Thanks for the offer, but I'll let you do it when you have time. ;-)
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
