On 30 Oct 2005, at 19:51, Lawrence Sanbourne wrote:
On 10/30/05, Laurence Harris <email@hidden> wrote:
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.
Do the STL stacks, vectors, and other collections automatically copy
the memory referenced by a pointer? This would surprise me.
I would use FSRefs by value here rather than storing pointers, i.e.
store the actual FSRefs in the vector rather than a pointer to a
FSRef. The overhead of copying 80 bytes will be so small as to be
unmeasureable. You may actually find that the copy overhead is less
than the malloc() overhead of allocating 80 bytes (but only Shark
will tell you).
The STL is software, just as Core Foundation is.
True, but what evidence do you have that CF is faster?
I know CF is "faster" only in that I don't have to rewrite anything!
One aim of STL containers is to be as efficient as raw C structures
such as C-style arrays, b-trees and linked lists, but give the
benefits of code reuse and type-safety. The main benefit though is
that the amount of code you need to write to use them is very small,
much less code than CFArray. This means you are much less likely to
make mistakes, which will make your code more reliable (without
sacrificing any performance). I've not used CFArray, but the amount
of code you need to write with all those CFDataCreate() calls looks
awful and is utter non-typesafe.
Finally, for tight loops, all those function calls to CFDataCreate()
etc will kill you. The STL vector code will all be inlined.
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 ] );
This code (internally) still has to allocate some new memory, use copy
the stuff at the FSRef * to it.
So, I'm well aware of the convenience of the STL, but I have no reason
to believe it's faster than CF.
Actually it probably won't allocate more memory - STL vectors
normally allocate memory in steps, typically by doubling the
allocation each time. This makes them quite efficient. If you know
approximately how many entries you might need beforehand, you can use
reserve() to pre-allocate the array (though you can of course exceed
this pre-allocation and it will automatically cope).
In your case I would pre-allocate say 1000 entries in the array -
this is only 80K, small potatoes on a sparse VM system.
Cheers,
Steve.
Steve Baxter
Software Development Manager
Improvision
+44-2476-692229
_______________________________________________
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
