-
Improvement
-
Resolution: Fixed
-
Minor
-
Plugin version 2.1.1
Jenkins 2.150.2
-
-
warnings-ng 4.0.0, analysis-model-api 3.0.0
First of all, the new plugin is great.
Some days ago i noticed a major change in the build performance of my project (http://83.169.43.181/jenkins/job/HtmlUnit/). After some checking i found that this is because the parsing of the output takes really long.
19:43:09 [Java] Sleeping for 5 seconds due to JENKINS-32191...
19:43:14 [Java] Parsing console log (workspace: '/var/lib/jenkins/workspace/HtmlUnit')
19:59:59 [Java] Attaching ResultAction with ID 'java' to run 'HtmlUnit #262'.
19:59:59 [Java] Using reference build 'HtmlUnit #261' to compute new, fixed, and outstanding issues
19:59:59 [Java] Issues delta (vs. reference build): outstanding: 0, new: 0, fixed: 0
19:59:59 [Java] No quality gates have been set - skipping
19:59:59 [Java] Health report is disabled - skipping
19:59:59 [Java] Created analysis result for 0 issues (found 0 new issues, fixed 0 issues)
Yes the log is really long, but this was not a problem in the past. With a bit more testing i found out that the log contains two really long lines with javascript inside. Looks like this lines are killing the parser.
Have attached the critical lines.
This is a log output for a fast run (one without the js lines nothing else changed).
22:37:19 [Java] Sleeping for 5 seconds due to JENKINS-32191...
22:37:24 [Java] Parsing console log (workspace: '/var/lib/jenkins/workspace/HtmlUnit')
22:37:24 [Java] Attaching ResultAction with ID 'java' to run 'HtmlUnit #263'.
22:37:24 [Java] Using reference build 'HtmlUnit #262' to compute new, fixed, and outstanding issues
22:37:24 [Java] Issues delta (vs. reference build): outstanding: 0, new: 0, fixed: 0
22:37:24 [Java] No quality gates have been set - skipping
22:37:24 [Java] Health report is disabled - skipping
22:37:24 [Java] Created analysis result for 0 issues (found 0 new issues, fixed 0 issues)
If you like i can provide the whole log also.
[JENKINS-55805] JavaDocParser is slow at parsing the log output
Ronald Brill
added a comment - Made already a suggestion:
Maybe using the regex with the first e.g. 400 chars of a line to make sure this is a candidate for a deeper analysis is an option to make the parser faster.
But if you like i can have a deeper look.
Ronald Brill
added a comment - Made already a suggestion:
Maybe using the regex with the first e.g. 400 chars of a line to make sure this is a candidate for a deeper analysis is an option to make the parser faster.
But if you like i can have a deeper look. Ronald Brill
added a comment - Another option:
Use https://www.brics.dk/automaton/ as regex engine.
Have done this successfully in the past for Wetator to increase performance.
Ronald Brill
added a comment - Another option:
Use https://www.brics.dk/automaton/ as regex engine.
Have done this successfully in the past for Wetator to increase performance. Interested in helping with this? I am open for any solution that does not break the rest of the tests 
Ronald Brill
added a comment - Ok will have a look. Ronald Brill
added a comment - Looks like my theory is correct, the regex is the show stopper. What do you think about limiting the content that is inspected by the regex. Did some tests and limiting the length to 4000 chars cures all the problems without failing tests.
Optional
- every subclass can provide a length restriction (default none)
- every subclass can restrict the line (default is to return the whole line)
- every subclass can overwrite the match and limit the line before calling the matcher
What do you think?
Ronald Brill
added a comment - Looks like my theory is correct, the regex is the show stopper. What do you think about limiting the content that is inspected by the regex. Did some tests and limiting the length to 4000 chars cures all the problems without failing tests.
Optional
every subclass can provide a length restriction (default none)
every subclass can restrict the line (default is to return the whole line)
every subclass can overwrite the match and limit the line before calling the matcher
What do you think? I think hard coding the 4000 limit is ok. We can make it configurable later on if really someone requires something different.
Ronald Brill
added a comment - Should i prepare a PR? Ronald Brill
added a comment - Ok PR is there, have implemented a more generic solution, hope you like it.
Ronald Brill
added a comment - Ok PR is there, have implemented a more generic solution, hope you like it. 
No.
The remaining parser that is slow is the JavaDoc parser. I don't see a simple way to improve the speed here without rewriting the parser. It currently has too many or conditions.
Do you have an idea how to solve such a problem in general? I think several of the parsers have a rather complex regexp.