Re: Best Way To Lookup From a Huge Table

FROM : John Stiles
DATE : Fri Mar 21 22:08:25 2008

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_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
> 
> ------------------------------------------------------------------------
>
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>