Slowness in next/prev error and set_error_markers: WORKAROUND

[chrisant]

I was frustrated by how long it took Ctrl-Shift-Down to skip through a bunch of errors I was deferring for later, and similarly how long it took set-error-markers to parse out the messages.  I figured it was probably some regex weirdness.  Then I noticed that slowness occurred only on specific lines, and I realized the slowness is because the regex isn't specific enough, and SE is doing some kind of post-processing of filenames to work around poorly phrased regex's.  At least in my situation, using the MSC compiler.

Change the "Visual Studio" regex to:

Code: [Select]

^(:i>|[ \t]@)(error-continuation |){#0?*}\({#1:i}(,{#2:i}|{#2})\) *\: {#3?*$}
Note the insertion of "(error-continuation |)".  The "error-continuation " string that exists in some errors was being treated as part of the filename.  The CPU spike and delays come from SE trying to fix the filename.  Adjusting the regex to avoid yielding poorly formed filenames solves the problem without CPU spikes.

Before:  set-error-markers took 3-5 minutes for less than 100 errors with CPU at 100%.
After:  set-error-markers is instant with no CPU spike at all.

Note:  I also disabled the regex's for languages and build systems that I never use.  The "Before" timing above is with those disabled, though, so disabling them is not a solution, but I figure there's no point having them enabled if I'll never need them.  VMMY.

HTH!
C

[Matthew]

Your approach was the correct one, and the one we intended when we moved to using a configuration dialog for this.

 For a little background...
Up until a couple versions ago, *all* of the error parsing expressions were globbed into one huge regular expression, exposed as a def_var. This worked fine for a while when customers were only expecting it to work with GCC and VC++. But as this feature became more widely used, more expressions were tacked on to support more tools. This became rather top-heavy, and we refactored it into a series of categorized expressions, and added the dialog to make it easier to add/remove/disable/reorder the expressions. However, in an effort to break as little as possible (but with the obvious performance penalty), the original gargantuan expression was still included as the "default" category.

The dialog is handy for creating and testing your modifications, but if you've got a dev team using a common set of tools, it may be easiest to have the modifications made once, and then share the configuration file. The expressions are saved in the file ErrorRE.xml in the root of the config directory.

[chrisant]

Makes sense, but could you perhaps update the default expression for the MS compilers?  I'm able to tweak things, and I don't mind tweaking things, but SE says it supports the Visual Studio compiler from MS and that makes us customers intuitively expect that the regex is right, or is at least being updated when it is discovered to need updating.  We customers are quirky folk, and sometimes are happier with "no default regexs, make your own" or "proper default regexs are supplied, add others for other compilers" than with "default regexes are supplied that work for the most common message type, and if you tend to make typos while coding and actually see errors a lot then you'll need to update the regexes based on the errors you see". 

Maybe consider removing whatever code is making SE go to 100% CPU for long periods of time to second guess faulty regexes and come up with a filename.