Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-20874

Slow FindBugsPlugin.start is wasted

    Details

    • Similar Issues:

      Description

      While waiting for a Jenkins instance to start up, which was quite slow, on a whim I took a thread dump. I found that Jenkins was initializing the FindBugs plugin; specifically FindBugsPlugin.start was calling FindBugsMessages.initialize, which apparently loads some several thousand line XML files. Note that this was a virgin $JENKINS_HOME—no jobs, no FB publisher configured.

      This is very bad. Plugins should avoid doing work in initializers unless they cannot avoid it, especially expensive work like this. Why not move this initialization to FindBugsMessages.getInstance, so that it is done if and when someone is actually using FindBugs?

      Also start seems to be setting the global org.xml.sax.driver, which it must not do. (It purports to restore the previous value, but fails to use a finally block for this, and does not consider the normal case that no such system property was set to begin with.)

        Attachments

          Activity

          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          In the core, we should profile which task is taking how long and get more insights into the startup time. Hopefully we'll find more low-hanging fruits.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - In the core, we should profile which task is taking how long and get more insights into the startup time. Hopefully we'll find more low-hanging fruits.
          Hide
          drulli Ulli Hafner added a comment -

          Well, it's less than a second we will gain but it is quite easy to change that the messages will be read on demand (but it has the drawback of a synchronized piece of code during Jenkins runtime, this is not needed currently). I think over the Christmas vacation I'll have some spare time...

          Would it help if we make some performance tests with Jenkins? I'm planning a lecture/project about "testing enterprise applications" in the summer term in our department: maybe my master students can set up a performance test suite to detect existing bottle necks. These tests could also run in CI to prevent that the performance degenerates if a new feature is added...

          Show
          drulli Ulli Hafner added a comment - Well, it's less than a second we will gain but it is quite easy to change that the messages will be read on demand (but it has the drawback of a synchronized piece of code during Jenkins runtime, this is not needed currently). I think over the Christmas vacation I'll have some spare time... Would it help if we make some performance tests with Jenkins? I'm planning a lecture/project about "testing enterprise applications" in the summer term in our department: maybe my master students can set up a performance test suite to detect existing bottle necks. These tests could also run in CI to prevent that the performance degenerates if a new feature is added...
          Hide
          jglick Jesse Glick added a comment -

          it's less than a second we will gain

          Maybe so but that winds up being a significant portion of startup time, especially if you are running interactive or Selenium tests, etc.

          Would it help if we make some performance tests with Jenkins?

          This would be wonderful!

          run in CI to prevent that the performance degenerates if a new feature is added

          I doubt that is practical—there would be too many false positives, since performance timings are always mere estimates (unless you can run in some very tightly controlled virtual machine). Anyway in some cases a slightly slower startup is a worthwhile price to pay for some crucial fix or major feature; it requires human judgment to decide whether a performance regression is a mistake, and if so, who should fix it.

          Show
          jglick Jesse Glick added a comment - it's less than a second we will gain Maybe so but that winds up being a significant portion of startup time, especially if you are running interactive or Selenium tests, etc. Would it help if we make some performance tests with Jenkins? This would be wonderful! run in CI to prevent that the performance degenerates if a new feature is added I doubt that is practical—there would be too many false positives, since performance timings are always mere estimates (unless you can run in some very tightly controlled virtual machine). Anyway in some cases a slightly slower startup is a worthwhile price to pay for some crucial fix or major feature; it requires human judgment to decide whether a performance regression is a mistake, and if so, who should fix it.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Christopher
          Path:
          plugin/src/main/java/hudson/plugins/findbugs/FindBugsMessages.java
          plugin/src/main/java/hudson/plugins/findbugs/FindBugsPlugin.java
          plugin/src/test/java/hudson/plugins/findbugs/FindBugsMessagesTest.java
          plugin/src/test/java/hudson/plugins/findbugs/parser/FindBugsParserTest.java
          http://jenkins-ci.org/commit/findbugs-plugin/eefcb731c13ee5521c72e16b7c54f64ebc02ea61
          Log:
          JENKINS-20874 lazy load FindBugsMessages singleton

          • implemented lazy initialization for FindBugsMessages singleton (using
            Initialization-on-demand holder idiom)
          • I assumed the SaxSetup wrapper in FindBugsPlugin.start() was only
            needed for the parsing of message xmls
          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Christopher Path: plugin/src/main/java/hudson/plugins/findbugs/FindBugsMessages.java plugin/src/main/java/hudson/plugins/findbugs/FindBugsPlugin.java plugin/src/test/java/hudson/plugins/findbugs/FindBugsMessagesTest.java plugin/src/test/java/hudson/plugins/findbugs/parser/FindBugsParserTest.java http://jenkins-ci.org/commit/findbugs-plugin/eefcb731c13ee5521c72e16b7c54f64ebc02ea61 Log: JENKINS-20874 lazy load FindBugsMessages singleton implemented lazy initialization for FindBugsMessages singleton (using Initialization-on-demand holder idiom) I assumed the SaxSetup wrapper in FindBugsPlugin.start() was only needed for the parsing of message xmls
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Ulli Hafner
          Path:
          plugin/src/main/java/hudson/plugins/findbugs/FindBugsMessages.java
          plugin/src/main/java/hudson/plugins/findbugs/parser/HexishString.java
          http://jenkins-ci.org/commit/findbugs-plugin/c8f4ffce5c6a33c475dbe5c902df2d00fd07ab4e
          Log:
          [FIXED JENKINS-20874] Fixed formatting.

          Compare: https://github.com/jenkinsci/findbugs-plugin/compare/3fd02468e97c...c8f4ffce5c6a

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Ulli Hafner Path: plugin/src/main/java/hudson/plugins/findbugs/FindBugsMessages.java plugin/src/main/java/hudson/plugins/findbugs/parser/HexishString.java http://jenkins-ci.org/commit/findbugs-plugin/c8f4ffce5c6a33c475dbe5c902df2d00fd07ab4e Log: [FIXED JENKINS-20874] Fixed formatting. Compare: https://github.com/jenkinsci/findbugs-plugin/compare/3fd02468e97c...c8f4ffce5c6a

            People

            • Assignee:
              drulli Ulli Hafner
              Reporter:
              jglick Jesse Glick
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: