Re: Best Way To Lookup From a Huge Table
Re: Best Way To Lookup From a Huge Table
- Subject: Re: Best Way To Lookup From a Huge Table
- From: John Stiles <email@hidden>
- Date: Fri, 21 Mar 2008 14:08:25 -0700
I'm using Thunderbird, dunno.
I only took issue with your statement of "this doesn't build a
convincing case for the STL option." I didn't agree with that, since the
STL code should be quite similar in code length and complexity and
appeared to generate identical performance while the underlying guts
were actually doing a more sophisticated task (copy instead of
reference, sorted instead of unsorted). Other than that, you've been
giving credit pretty much where it's due.
Michael Ash wrote:
On Fri, Mar 21, 2008 at 4:51 PM, John Stiles <email@hidden> 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
------------------------------------------------------------------------
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden