Bug 1934229 - List page text filter has input lag
Summary: List page text filter has input lag
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.8
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.8.0
Assignee: Jon Jackson
QA Contact: Siva Reddy
Whiteboard: Scrubbed
Depends On:
TreeView+ depends on / blocked
Reported: 2021-03-02 18:19 UTC by Jon Jackson
Modified: 2021-07-27 22:51 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Filter logic was being applied on every key stroke when using list page name filter Consequence: When there are a large number of items on the list page, the filter logic would cause lag on the name filter input Fix: Debounce the filter function with a 200ms delay Result: Name filter input works smoothly and filter is only applied after a 200ms delay without new input.
Clone Of:
Last Closed: 2021-07-27 22:49:01 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift console pull 8821 0 None open Bug 1934229: Improve performance of ToolbarFilter 2021-04-29 14:25:42 UTC
Red Hat Product Errata RHSA-2021:2438 0 None None None 2021-07-27 22:51:31 UTC

Description Jon Jackson 2021-03-02 18:19:42 UTC
Description of problem:
Performance of the text filter on the list pages can get very sluggish with larger numbers (n) of items. Even with n as low as 20, there is noticeable input lag. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Visit Workloads > Secrets page
2. Select "All Namespaces" from the Project dropdown (should be hundreds if not thousands of Secrets on most clusters)
3. Start typing a term in the "Search by name..." filter

Actual results:
There is noticeable input lag. With n in the dozens, it's probably only about 200 milliseconds of lag, but still noticeable. Lag increases with n and can even take longer than a second (estimated) in some cases.

Expected results:
Text input should be immediately responsive, regardless of the list length.

Additional info:
This is happening on a MacBook Pro with average performance (maybe even above average) and plenty of available CPU/memory. I would imagine the issue would get better or worse depending on the performance and available compute resources of the user's machine.

Comment 1 Jon Jackson 2021-04-07 13:24:52 UTC
Started looking into this. The performance issue doesn't seem to be tied to the filtering logic itself. Even after removing the filtering logic altogether, there were still performance issues. I suspect that updating the URL search params is causing extra re-renders. Will investigate more next sprint.

Comment 4 Siva Reddy 2021-06-11 17:10:05 UTC

Steps to verify:
  Did a comparison between 4.7 and 4.8 and you do see the input gets stuck in 4.7 but it runs smooth in 4.8

1. login to console and navigate to Workloads>Secrets
2. Uncheck all in the filter drop down and select "Name" in the next drop down and type "sdn-controller" in the "Search by name" input box.
3. It will display 4 filtered values that have "sdn" "controller" words (actually it is filtering by characters)
4. press and hold backspace in the name filter and watch the url getting updated and the characters in the "Search by name" 
    input box

in 4.7 you see a significant time lag between the updates in the url and input box characters where input box chars are updated after a delay
but in 4,8 both of them getting updates almost simultaneously.

  there is definitely improvement and hence it is verified

Comment 7 errata-xmlrpc 2021-07-27 22:49:01 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.