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

ListView.getItems makes too many passes through jobs list

    • Jenkins 2.239

      Since pull 757 in 1.512, ListView can include items in subfolders. Unfortunately it seems that getItems calls ViewJobFilter with anomalous arguments: items may be a superset, rather than a subset, of allItems.

      Should be better tested, and simplified by inlining the includeItems method, which could also improve performance by removing the double traversal of the job hierarchy (which checks ACLs each time through).

          [JENKINS-20052] ListView.getItems makes too many passes through jobs list

          Jesse Glick created issue -
          Jesse Glick made changes -
          Assignee Original: Jacob Robertson [ jacob_robertson ] New: Jesse Glick [ jglick ]

          Daniel Beck added a comment -

          Didn't JENKINS-18721 resolve the performance issue sufficiently?

          Daniel Beck added a comment - Didn't JENKINS-18721 resolve the performance issue sufficiently?

          Jesse Glick added a comment -

          Looks like JENKINS-18721 made some improvements, but getItems still looks to go through all jobs twice: once in includeItems, once in the loop to translate names into items.

          Basically the issue is that instead of doing the obvious thing—looking up explicitly-specified names using the method that exists for that purpose, then scanning recursive items whose relative name match the regexp and adding those in—the view is scanning recursive items, adding them to the name list, then going back and scanning recursive items again and collecting those whose (relative) names match the list. And the job filters are reported to be called with the wrong arguments: the direct children of the folder.

          Jesse Glick added a comment - Looks like JENKINS-18721 made some improvements, but getItems still looks to go through all jobs twice: once in includeItems , once in the loop to translate names into items . Basically the issue is that instead of doing the obvious thing—looking up explicitly-specified names using the method that exists for that purpose, then scanning recursive items whose relative name match the regexp and adding those in—the view is scanning recursive items, adding them to the name list, then going back and scanning recursive items again and collecting those whose (relative) names match the list. And the job filters are reported to be called with the wrong arguments: the direct children of the folder.
          Jesse Glick made changes -
          Link New: This issue depends on JENKINS-18721 [ JENKINS-18721 ]
          Daniel Beck made changes -
          Labels Original: folders performance New: folders lts-candidate performance
          Jesse Glick made changes -
          Link New: This issue is duplicated by JENKINS-20143 [ JENKINS-20143 ]
          Georg Sash made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Georg Sash made changes -
          Status Original: In Progress [ 3 ] New: Open [ 1 ]
          Jesse Glick made changes -
          Link New: This issue depends on JENKINS-20143 [ JENKINS-20143 ]

            raihaan Raihaan Shouhell
            jglick Jesse Glick
            Votes:
            3 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: