B4: Setting error markers and next error taking very long time

[rowbearto]

I found that one of the default error parsing expressions provided in the clean config, and also in my config, was triggering the 695 false positives in my build.

I also think that the reason I had 35 exclusions, built up over many many years, is because the default error parsing captured so many things that whenever I wanted to exclude anything I would quickly add it to exclusions, and over time I got to 35+ exclusions.

I never took the time until today to reexamine why I was getting so many false positives and adjust how error parsing is done. It was faster in the past to just add another exclusion.

I still think that SlickEdit has an issue because even when I turn off the exclusions, with 695 error markers there is quite a long pause before SE is usable again. But after performing my refinement of error parsing, it is no longer an issue for me personally anymore.

The problematic default error parsing is in the "default" Category and is the "def1". By turning this off, I got rid of my 695 false positives. However turning this off also excluded finding gcc errors and warnings that I would like to see.

SlickEdit may want to reconsider the default error parsing rules to not catch so many false positives.

So I made a much more restrictive error parser that doesn't have all the false positives, and now I only need 1 exclusion.

For gcc formatted errors I now use this:

Code: [Select]

^{#0?+}\:{#1:i}\:({#2:i}\::b|:b){#3(error\:|warning\:|undefined:breference|note\:)?+}$
It will match what gcc outputs in sample messages such as:

Code: [Select]

file:linenum:col: (error:|warning:|undefined reference|note:) message
or without the column

Code: [Select]

file:linenum: (error:|warning:|undefined reference|note:) message
By being this restrictive, I no longer need many of my exclusions for when timestamps were output to the build log, which had colon characters that created a false positive.

I added one restriction to exclude messages coming from our makefiles, which are overdue to be fixed, but it is not my responsibility. So I added 1 exclusion:

Code: [Select]

^(?+\.mk|Makefile)\::i\: warning\:
Which will exclude things like:

Code: [Select]

Makefile:linenum: warning: message
anyfile.mk:line: warning: message

[Clark]

For me, when I remove the excludes, this finishes very fast.  <2 seconds.

Because of this, I started to see if it is the number of excludes or a specific exclude. For me, I can leave all the excludes enabled except for the "csharp" exclude and performance is always good. There's something funky going on with the "csharp" exclude. It looks ok. I even tried tweaking it.

Then I disabled all excludes except for the "csharp" exclude. Once I do that, the performance is horrible. Seems like something weird is going. I'll have to investigate what's going on with it.

My results are always consistent. Doesn't matter whether I restart.

[rowbearto]

I just moved from beta4 to 24.0.0.7. I went back to my old user.cfg.xml to try out 24.0.0.7. Now it is very slow with the restart, even with excludes enabled. Perhaps the difference in our outcomes all along was that I was still on B4 and you were using a more recent version?

And with 24.0.0.7 when I disable the excludes it is very fast.

So now with 24.0.0.7 I'm seeing what you see.

Perhaps if you back to beta4 you can see what I was reporting previously.

Regarding the csharp exclude, I just added that a few days ago and it also lines up with when I first started seeing this issue.

[Clark]

I'm pretty sure I found the problem.

Edit error.e and change line #2423 to the following:

Code: [Select]

      if (folder_array[i].m_enabled && pos(langRE, folder_name, 1, "ir") == 1) {

The problem is that the logic is backwards.

Reload error.e and restart. That should fix the problem. This same issue exists in v23.

[rowbearto]

Well after applying your error.e fix, 24.0.0.7 is going back to the behavior I had before. I think you fixed one issue but there is still a remaining issue.

After a fresh restart, the build is very fast, like I was observing before with B4. So this is fixed.

Then I loaded a python file into a buffer and did a 2nd build, it is very slow when I do that. Saying "setting error markers..." and then many (location x%) Searching..."

[rowbearto]

Then, after the 2nd build loading the python file, I disable excludes, a 3rd build is still very slow. But I only see in the status bar "Setting error markers" for a long time. I don't see the "(location x%) Searching..." in the status bar in this case.

[Clark]

I'm trying to reproduce bad performance. Not getting it right now. Editing a Python file too. There aren't any language specific regular expressions (that's where I found the bug). It shouldn't matter what type of file you edit because there are no language specific regular expressions.

[rowbearto]

I uploaded errormarkerslongtime2.tar.gz to support.

Look for the README file in there. I included some stuff in there to make your system more like mine, so maybe you will be able to reproduce.

Another suggestion is to try to use the Virtual Machine you got from me.

[Clark]

Before I do that. Here's a new error.e.  Load it and restart SlickEdit.

Once you see that the build is slow, put the focus on the debug window and press Ctrl+C to copy all the debug messages to the clipboard. You can post the debug here. It maybe best to put them in a file and attach the file.

I want to check what the regex is for searching for an error to verify that no excludes are in there. That was the bug.

[rowbearto]

I don't see a debug window? How to bring that up?

[rowbearto]

You also want me to turn off the excludes?

[Clark]

I don't see a debug window? How to bring that up?

When you run the Build command for your project, you should see a debug window come up.

Keep the excludes on.

[rowbearto]

The debug window is not popping up. I left the excludes on. Maybe the "say" statement you added is not getting executed? I placed the error.e file into the macros directory while SE was not running, then started SE.

[Clark]

You have to manually load the macro Macro>Load Module...

This will compile the macro if it is out of date and load the resulting pcode. Make sure there is read/write permissions to the directory the macro resides in.

[rowbearto]

Macro>Load Module is what I was missing.

When I use the error.e file with just the fix, and without your debug print, now with the 2nd build after loading the python file, the error marker setting is very fast!

I didn't try your second error.e with the debug prints, as the first one seems to solve the problem, and I was missing the part about Macro>Load Module.

Thanks Clark!