Cocoa mail archive
Re: Best Way To Lookup From a Huge Table
FROM : Michael Ash
DATE : Fri Mar 21 22:03:34 2008
On Fri, Mar 21, 2008 at 4:51 PM, John Stiles <<email_removed>> wrote:
> It's fine that you are uncomfortable with STL, but there's nothing about
> your results that makes me think "this doesn't build a convincing case for
> the STL option." If its performance is on par, then it's a highly convincing
> case. std::map actually does more than NSDictionary—it sorts its entries
> instead of keeping them in random order.
And if said capability were relevant to the problem at hand then that
would be an advantage, but it's not so it's not.
The thing that didn't make a convincing case for the STL option was
being informed that a comparable amount of work took, using first-pass
code, over one minute to execute, and that this could be brought down
to reasonable levels only through a fair amount of profiling and
compiler twiddling. The post to which I replied described a laborious
process of implementing code using the STL and then optimizing it only
to get results which I would have expected using naive code.
My own results reveal that it's easy to get good performance out of
the STL in my case. Presumably my compiler isn't sucking as hard, or
the work I'm giving it is easier.
> Also, it copies its keys instead of
> just keeping a reference to them, which is also more work—it would be a much
> fairer test if you used std::string* pointers for your keys and values
> instead of std::string objects, but it'd also be a little more work since
> you'd need a custom comparator and you'd need to consider memory management
> (which boost smart pointers apparently can manage pretty well).
I put roughly equal amounts of work into both tests. Of course any
code can be further optimized with more work. My point is that you
generally don't need to. The code to create an NSMutableDictionary and
insert my keys and values into it is literally three lines of code,
took about that many seconds to write, and still resulted in very good
performance.
> YMMV, but I like the capabilities of the STL and I think it's a pretty
> powerful tool to have in one's toolbox. Not that I think you should be
> forced to use it—feel free to use Foundation classes if you like them
> better—but don't let bias stand in the way of reasonable comparisons.
You say that as if to imply that I have been letting bias stand in the
way of reasonable comparisons. Could you please point out where you
think I've done that? The one place where I actually allowed my
personal distaste for it to enter my post, it was explicitly stated as
being my own personal preference and nothing more.
On a completely unrelated note, whatever it is that your mail program
is doing to indicate quoting renders gmail completely unable to
properly quote the quoted portions of your post. Everything just ends
up in one big blob.
Mike
DATE : Fri Mar 21 22:03:34 2008
On Fri, Mar 21, 2008 at 4:51 PM, John Stiles <<email_removed>> wrote:
> It's fine that you are uncomfortable with STL, but there's nothing about
> your results that makes me think "this doesn't build a convincing case for
> the STL option." If its performance is on par, then it's a highly convincing
> case. std::map actually does more than NSDictionary—it sorts its entries
> instead of keeping them in random order.
And if said capability were relevant to the problem at hand then that
would be an advantage, but it's not so it's not.
The thing that didn't make a convincing case for the STL option was
being informed that a comparable amount of work took, using first-pass
code, over one minute to execute, and that this could be brought down
to reasonable levels only through a fair amount of profiling and
compiler twiddling. The post to which I replied described a laborious
process of implementing code using the STL and then optimizing it only
to get results which I would have expected using naive code.
My own results reveal that it's easy to get good performance out of
the STL in my case. Presumably my compiler isn't sucking as hard, or
the work I'm giving it is easier.
> Also, it copies its keys instead of
> just keeping a reference to them, which is also more work—it would be a much
> fairer test if you used std::string* pointers for your keys and values
> instead of std::string objects, but it'd also be a little more work since
> you'd need a custom comparator and you'd need to consider memory management
> (which boost smart pointers apparently can manage pretty well).
I put roughly equal amounts of work into both tests. Of course any
code can be further optimized with more work. My point is that you
generally don't need to. The code to create an NSMutableDictionary and
insert my keys and values into it is literally three lines of code,
took about that many seconds to write, and still resulted in very good
performance.
> YMMV, but I like the capabilities of the STL and I think it's a pretty
> powerful tool to have in one's toolbox. Not that I think you should be
> forced to use it—feel free to use Foundation classes if you like them
> better—but don't let bias stand in the way of reasonable comparisons.
You say that as if to imply that I have been letting bias stand in the
way of reasonable comparisons. Could you please point out where you
think I've done that? The one place where I actually allowed my
personal distaste for it to enter my post, it was explicitly stated as
being my own personal preference and nothing more.
On a completely unrelated note, whatever it is that your mail program
is doing to indicate quoting renders gmail completely unable to
properly quote the quoted portions of your post. Everything just ends
up in one big blob.
Mike
