Re: Painfully slow searching

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

Pete Hall wrote:
> I have no sage advice about Brian's situation. Could network bandwidth
> be a contributing factor? I'd also like to mention that I'd be really
> unhappy if I had to give up the LPEX editor and go back to SEU.
>   
Agreed.  That's the benefit of a client/server environment, and why I 
can live with a few seconds of delay when opening a new member.  The 
benefit gained by the editor offsets the immediate gratification effect 
of instant open in PDM.

> That said, in a prior life, I did software conversions, and text
> searches of libraries full of source members were absolutely essential.
> I dispute that this is a unique requirement, which can be ignored. I
> know I'm not the only one that's ever done contract work of that nature.
> If it's a performance issue, it needs attention.
>   
I'm not trying to minimize the need for text searches.  They are needed 
- occasionally.  My only question had to do with *how often* they're 
needed.  My contention is that a few minutes delay once a week is a much 
different issue than a few minutes delay once an hour.

Which led me to the subsequent question of what text search was being 
used for.  There are a number of things that a good text search helps 
on.  You mentioned conversion.  I would add database reorganization or 
field size changes.  But I'd also have to argue that for the most part 
the text searches in those situations are batch processes that take a 
long time.

Tim's original post was about searching 98 members in a filter.  If you 
really are doing a mass search, don't use a filter, search the whole 
file.  Tim also mentioned the auto-open in PDM, and that's not exactly 
an apples-to-apples comparison, because auto-open only searches to the 
first hit, whereas an RDi search always searches all the members and 
returns the results.

So to me the question still is: where exactly is the performance issue?  
Is it that a mass search takes a long time?  Or that you do a lot of ad 
hoc searches and you want to open the first member right away?  Because 
if it's the latter, I could see an option to push the matches down to 
the workstation a little quicker.  In fact, I could even see an option 
in the search that would tell RSE to auto-open the first member.  I 
don't think I'd go so far as to open all of the matches, but maybe just 
the first.  But I'd still argue that if you are doing a lot of ad hoc 
searches on a regular basis, then maybe you need a slightly different 
tool, or maybe a different methodology (such as bringing the source local).

Joe