Beta3: Find in Files

[sraffens]

The "Exclude:" works differently then v18.

I have long searches with v18 so I add a list of directory the that I can skip, cutting 60 minutes off the search.

now in v19 the search time is back to taking a long time 1:31:00 and still running.
The directories in the library that I should be skipping are being search.

*\_gsdata_\*;*\siplib\*;*down\* is the exclude string, should this work?

[jporkkahtc]

I'm pretty sure in V18 it didn't support wildcards on directory names.


So, I use something like
"bin\;gen\;*.obj;*.lib"


To exclude the "bin" and "gen" directories, and all files ending in  "obj" or "lib".

[Clark]

The "Exclude:" works differently then v18.

I have long searches with v18 so I add a list of directory the that I can skip, cutting 60 minutes off the search.

now in v19 the search time is back to taking a long time 1:31:00 and still running.
The directories in the library that I should be skipping are being search.

*\_gsdata_\*;*\siplib\*;*down\* is the exclude string, should this work?

Your directory exclusions are incorrect. They must end with a slash (windows: dir\ Unix dir/).

[sraffens]

I am in a windows machine, and add \ to the end of the exclude string, it is still search these directories

*\_gsdata_\*\;*\siplib\*\;*\down\*\
*\_gsdata_\**\;*\siplib\**\;*\down\**\

I still think that my syntax is wrong.

[Clark]

You still have a bad directory exclusion.

Try this:    "siplib\" with nothing else. All the extra stuff you have is and messing things up.

[sraffens]

v18 11minutes
v19 1 hour, 12 minutes

Deleted 19.0.0 in My SlickEdit Config
Started v19, it copied v18
Started GUI Find in File changed Exclude string
String was found
Checked the time - 1 hour, 12 minutes
Exit SlickEdit

Start v18
Started GUI Find in File changed Exclude string
String was found
Checked the time - 11 minutes
Exit SlickEdit

If this is expected - never mined

[Lee]

 @sraffens:  Could you list all the search options you are using for this particular search?  And what is the difference in Total files searched between v18 and v19, it is listed at the bottom of the Search Results.

[sraffens]

v18

Find all "ppctrl_logging_id_number", Match case, Regular expression (UNIX), Subfolders, "t:\apps\stx326\src", "*.c;*.cxx;*.cpp;*.h;*.hpp;*.hxx;*.inl;*.f;*.ic;*.bld;*.rtmdl;*.txt;*.prm;*.pl;*.pm;*.e;*.fstat;*.lua;*.xml:*.x", Exclude: "_gsdata_\;siplib\;down\"
...
Total found: 5     Matching files: 3     Total files searched: 6434


v19
Find all "ppctrl_logging_id_number", Match case, Regular expression (UNIX), Subfolders, "t:\apps\stx326\src", "*.c;*.cxx;*.cpp;*.h;*.hpp;*.hxx;*.inl;*.f;*.ic;*.bld;*.rtmdl;*.txt;*.prm;*.pl;*.pm;*.e;*.fstat;*.lua;*.xml:*.x", Exclude: "_gsdata_\;siplib\;down\"
...
Total found: 5     Matching files: 3     Total files searched: 6417




while the search is going on v19 is almost useless, a lot of wait cursor, mouse controls are missed, changing files tabs will display the wait cursor, slow to respond to keyboard but will dump what is in the type ahead buffer.

[Clark]

What OS are you running? Is Samba involved?

If there is this much of a difference, this is definitely fixable. Could be a mouse pointer performance issue (had one of those before). If not, it has something to do with file I/O. I just hope we can reproduce this.

[sraffens]

Windows 7

Yes Samba is involved

I ran this same test on my laptop. The v18 ~2 minutes ,v19 ~3 minutes
laptop is a 8GB 2.4 GHz i7 Windows 7 - 2013
     CPU usage during the search, 7 cores mostly idle, 1 core about 50%
desktop is a 4GB per CPU, dual 3.0 GHz X5365 - 2008
     CPU usage during the search, all 8 cores almost idle

I have toying with the idea of syncing my local hard drive with the server that I Samba on and search the file on my local hard drive.

I have that configuration on my laptop and sync changes later.

[Clark]

I've done some preliminary tests and haven't found anything obvious yet. The mouse pointer code does seem to be slowing things down a little in v19 on Windows 7 but it's pretty insignificant. If I remember correctly, the previous mouse pointer performance problem we had was only very noticeable on Windows 8.  I'll have to retest this on Windows 8 but I don't think this is your problem.

There's another performance problem I'm seeing which could be related to your problem. The difference is I'm testing on a network which is NOT samba, and likely has way better performance. Even when we set up Samba, we have way better performance. Believe it or not we try not to buy the best stuff so fast so we can detect performance problems. In fact, I only run with a debug editor. The machine I have right now is a screamer. Even our network servers are really good.

[Clark]

Hmm..There's definitely a problem with the new recursive list code but only on Windows. The symbolic link resolving code on windows has a problem. The recursive listing for multi-file searching is done on the main thread. Is the main thread completely hung up for a while?

[sraffens]

Is the main thread completely hung up for a while?

I have had the window go white (not responding) just for a moment and then go to a wait cursor.

The edit slows down:

while the search is going on v19 is almost useless, a lot of wait cursor, mouse controls are missed, changing files tabs will display the wait cursor, slow to respond to keyboard but will dump what is in the type ahead buffer.

[sraffens]

I changed the search to \\server\apps\stx326\src and it like night and day.

The search completed in 10 minutes, there was no slow down

[Clark]

I'm pretty sure the problem is due to resolving symbolic links for paths on Windows (not a problem on Unix or Mac). If you have remote source with tons of directories, it will be slow. If you have tons of files but not as many directories, performance will be fine. If you are recursing source on a local SSD, I wouldn't expect much performance degradation at all.