Re: Fastest way to search text file for string
From: Drebin (thedrebin_at_hotmail.com)
Date: 09/21/04
- Next message: craig: "Does anyone know what this error might mean?"
- Previous message: Nicholas Paldino [.NET/C# MVP]: "Re: non-class methods"
- In reply to: Julie: "Re: Fastest way to search text file for string"
- Next in thread: Julie: "Re: Fastest way to search text file for string"
- Reply: Julie: "Re: Fastest way to search text file for string"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 21 Sep 2004 15:49:05 GMT
Julie,
Just one other random thought, if I may. I guess the reason why you are
finding so much resistance is that pretty much everyone - except for you -
finds "solutions" in their jobs and remains open-minded in their work. Very
rarely are we asked to blindly "fill these requirements". Our industry is
such that, most companies simply can't afford to work that inefficiently.
Instead, most companies give a developer a "problem" and we are to use our
expertise to find the most efficient solution. "Efficient" means not only
the fastest to implement, but also the the most scalable and easiest to
change.
In other words, when we hear such unreasonable requirements as you've
vaguely defined, everyone's first reaction is to get a handle on those,
because they don't sound reasonable. When someone comes to me with with
outrageous requirements, I don't even BOTHER trying to answer the original
question, because 99% of the time, they don't have a handle on the problem.
But I'm gathering from your reaction and style that you likely work in the
gov't or aerospace - and I know that is a completely different mindset
there.
Anyhow - for future reference, it would probably be a big time-saver if you
were to actually share (in some level of detail) what your requirements are.
What IS the format of this data? Because without that, you come off as an
inexperienced and stubborn developer that is not pushing back on
unreasonable requirements when you CLEARLY should be (in our minds). So, if
you want people to stop reacting to your requirements, it might be best to
actually go into some detail about why they are so immutable so people can
get past it - and start helping with your actual problem.
For whatever it's worth..
"Julie" <julie@nospam.com> wrote in message
news:414FB738.C3C73C6E@nospam.com...
> James Curran wrote:
> >
> > Daniel O'Connell [C# MVP] wrote:
> >
> > > For what its worth, this heavy push for a database is probably
> > > foolish.
> >
> > But I'm not pushing heavily for a database. I'm pushing heavily in
> > favor of looking beyond a very naive reading of the requirements, and
> > putting some knowledge of the domain space behind the problem.
>
> Thanks for the insult of calling me naive.
>
> I really find it hard to believe that you think that I can't understand
what my
> requirements are.
>
> > For example, I have trouble believing that the input data here
> > ("datafiles from external laboratory instruments") are completely
free-form.
> > There's probably recognizable rows & columns. Further, I don't believe
> > searching would generally be limited to one search per file, so reading,
> > indexing, do several indexed searches, and then expiring the indexing
would
> > probably be faster than doing several simple text searches.
>
> I still don't see where I'm asking for anything faster than 1 hit in a 100
MB
> file in 10 seconds or less. That is all that the performance requirement
> dictates. Anything more is completely wasted effort.
>
> I appreciate your comments and suggestions, but please, don't become so
focused
> on what you think is necessary that you completely ignore what I know to
be the
> requirements.
>
> Thanks
- Next message: craig: "Does anyone know what this error might mean?"
- Previous message: Nicholas Paldino [.NET/C# MVP]: "Re: non-class methods"
- In reply to: Julie: "Re: Fastest way to search text file for string"
- Next in thread: Julie: "Re: Fastest way to search text file for string"
- Reply: Julie: "Re: Fastest way to search text file for string"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|