Re: Search Algorithm
From: Marc Rochkind (rochkind_at_basepath.com)
Date: 08/15/03
- Next message: Chuck Dillon: "Re: Search Algorithm"
- Previous message: Fletcher Glenn: "Re: Search Algorithm"
- In reply to: Fletcher Glenn: "Re: Search Algorithm"
- Next in thread: Chuck Dillon: "Re: Search Algorithm"
- Reply: Chuck Dillon: "Re: Search Algorithm"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 15 Aug 2003 14:19:26 -0600
On Fri, 15 Aug 2003 20:09:27 GMT, Fletcher Glenn <f-g-l-e-n-n@quest.com>
wrote:
> Marc Rochkind wrote:
>>
>> On Fri, 15 Aug 2003 08:40:36 -0700, John Smith <John_Smith273@cox.net>
>> wrote:
>>
>> [snip]
>>
>> > I was considering hashes but they are not suitable for my
>> > application since my function would be called from a non-C language.
>> >
>>
>> I don't understand this... can you explain?
>>
>> How many entries are there? How critical is the search time? Without
>> this
>> info, it's impossible to know what's best. If the time is not critical,
>> it
>> is a waste of time to even ask the question. If the entries are few, you
>> can't beat linear search.
>>
>> Generally, the approach is:
>>
>> 1. Implement linear search.
>> 2. Profile the app.
>> 3. Reimplement the search when it rises to the top of the priority list
>> of
>> things to do, if ever.
>>
>> --Marc
>
> This is a rather naive assessment. If you know going in that the
> list could be very large, it is better to design efficiency in at
> the outset instead of ignoring a potential problem and hoping that
> you might someday have time to handle it.
>
Well, if you read "ignoring a potential problem" into my post, then I
haven't been clear. What should be done at the outset is to design in the
ability to change design decisions that might have to be changed. (A
principle of modular programming that predates OO by a decade or so, and
since made even easier with OO.)
Making those fined-grained, limited-scope design decisions should not be
done at the outset. Rather, the emphasis should be on correctness, clarity,
and speed of development. Runtime efficiency is at most fourth. That way
there's time to get the overall architecture right, and modules are
available earlier for integration and system testing rather than later.
The problem with early optimization is that development time and money get
exhausted during the initial development, since it's rare that the
information about where to optimize is available at that time.
So, on the whole, I would strongly disagree with your recommendation.
--Marc
- Next message: Chuck Dillon: "Re: Search Algorithm"
- Previous message: Fletcher Glenn: "Re: Search Algorithm"
- In reply to: Fletcher Glenn: "Re: Search Algorithm"
- Next in thread: Chuck Dillon: "Re: Search Algorithm"
- Reply: Chuck Dillon: "Re: Search Algorithm"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|