Long freeze when double-clicking on build window

[paulio]

Hi

Our build system outputs a lot of supplementary information during a build, as well as compiler errors and so forth. A problem I encounter quite often is that when double-clicking in the build window, I will slightly 'miss' the line I meant leading to Slick freezing for ages whilst it tries to parse some other line that isn't an error and eventually yielding a 'find file' dialog box.

I have played around (a lot) with the regular expression 'exclusions' in the error parsing, but this problem is persistent. Along with this I also frequently find that the build window will just forget all its rules, and double clicking even on a valid error will result in Slick jsut trying to open whatever single word is under the cursor as if it were a file - again yielding a lengthy wait and a find file box. Restarting Slick seems to fix this.

Anybody seen/fixed these kind of issues? It's driving me nuts.

[Dennis]

The delay you are seeing is related to time SlickEdit is spending getting the file list for your workspace and trying to determine if the "filename" found on the line you clicked on matches a file in your workspace.  There were some inefficiences in the code that does that in 13.0.  I suggest getting the hot fix on Monday, which has some improvements to that code path.  Also the next patch (13.0.1) for SlickEdit will have further performance improvements in the same area.  Note that if your projects use wildcards or are just plain extremely large, it's fair to expect it to take a while, especially in the error case where you click on an error that does not have a valid file name.  I have not seen the second issue you describe.

[hs2]

That are really good news that we can expect a number of performance improvements in v13.0.1 !
I'm looking forward to the next dot release appearing hopefully soon
Thanks SlickTeam, HS2

[asipe]

Note that if your projects use wildcards or are just plain extremely large, it's fair to expect it to take a while

I've wondered this.   What would you say is the performance penalty incurred for using wild cards?   I have several fairly large projects and all of them use wildcards.  If converting them to specific file entries would improve performance a noticeable amount I'd change them over.

Thanks -andy

[Dennis]

Excellent question, and one that I've actually been eager to post an answer for.

First, SlickEdit's wildcard project support is dynamic.  Maybe too dynamic -- if I had time to redesign it, I would dial it back.  What does this mean?

1) When you start SlickEdit, or when you open a wildcard project/workspace in SlickEdit, it does a file scan at that point to find all the files matching your wildcard specifications.

2) When you rebuild your workspace tag file, it does a file scan to find the files matching your wildcards.

3) When you do a build, or when you do next-error or double-click in the build window to go to an error, it may have to do a file scan to find the files matching your wildcards.

4) A multi-file search of your workspace or project will also trigger a file scan to find files matching your wildcards.

5) Closing and re-docking the Project to Files tool windows may trigger a file scan to find the files matching your wildcards.

The assumption was that it is easy enough to create a project and add files using "Add Tree", and also pretty easy to add new files as you go along, so if you are using wildcard projects you want a whole other level of dynamic behavior, and that is what wildcard projects attempt to provide.  There is no realistic, cross platform (and file-system independent) way to know when new files pop up in the project directory tree, so we attempt to get a fresh list whenever we need it.

Normally, this is no big deal with small projects, we can get a file list very fast.  And those are the sort of quicky projects that wildcards were intended for.  However performance neccessarily breaks down when you put the source code on a remote file system or cross the 10,000 file boundary (that's not a real boundary, 10,000 files is just the line between having a lot of source code and having a silly amount of source code).

13.0.1 is going to add more in-memory project file list caching.  This will improve performance dramatically for certain operations for all project types, but especially for projects with wildcards.  However, it will not improve performance for initial startup and initial project/workspace open, which, with a wildcard project will still require a file scan.

Recommendations:  unless your projects are under 1000 files and on local file systems, if it is not too much of an inconvenience, replace the wild cards with Add Tree's, and let the project file manage the file list.

[asipe]

Sounds like it will be a worth while change.   I don't mind the start up cost to much, but the searching one really is painful.

Thanks -andy

[paulio]

The delay you are seeing is related to time SlickEdit is spending getting the file list for your workspace and trying to determine if the "filename" found on the line you clicked on matches a file in your workspace.  There were some inefficiences in the code that does that in 13.0.  I suggest getting the hot fix on Monday, which has some improvements to that code path.  Also the next patch (13.0.1) for SlickEdit will have further performance improvements in the same area.  Note that if your projects use wildcards or are just plain extremely large, it's fair to expect it to take a while, especially in the error case where you click on an error that does not have a valid file name.  I have not seen the second issue you describe.

Hi,

I experience no delay when clicking on a valid line. Only when I slightly 'miss' and click some random build output - at which point the problem occurs.