Thank you for your cogent arguments in favor of using the STL. Rather
than describing the STL's implementation of various aspects of this
and then assuming CF does it worse, you describe some real differences
between the implementations of STL and CF, and I find your arguments
convincing.
Honestly, though, I've lost interest in this debate. As I said
earlier, for my purposes this code needs to perform well on
directories of only a few hundred KB in size, usually with no more
than about three subdirectories.
The code I sent to the list performs reasonably for medium-sized
applications and has been reviewed and tested by several experienced
developers for correctness. (This is more than many major software
companies can say about their code!) If anyone would like to improve
the code and send a new version to the list with performance
measurements indicating how brilliant it is, I certainly won't object.
Cheers,
Larry
On 10/30/05, Steve Baxter <email@hidden> wrote:
>
> 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
>
>
--
Larry Sanbourne
email@hidden
_______________________________________________
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
