Opened on 03/06/2018 at 05:57:34 PM
Closed on 09/05/2019 at 05:48:36 PM
Last modified on 10/08/2019 at 06:04:31 PM
#6450 closed change (fixed)
[meta] Optimize options page for large amounts of filters
| Reported by: | greiner | Assignee: | |
|---|---|---|---|
| Priority: | Unknown | Milestone: | |
| Module: | User-Interface | Keywords: | |
| Cc: | wspee, saroyanm, agiammarchi, mapx | Blocked By: | #2708, #6440 |
| Blocking: | Platform: | Unknown / Cross platform | |
| Ready: | no | Confidential: | no |
| Tester: | Unknown | Verified working: | no |
| Review URL(s): | |||
Description (last modified by greiner)
Background
We've been encountering various issues when modifying large amounts of custom filters in the options page at once in #6440. Therefore we should make optimizations across our code base to better support such large batch modifications.
There are various areas where we can reduce the overhead such as:
- message passing
- use long-lived connections
- reduce the amount of data
- reduce the amount of messages
- filter loading
- implement lazy loading
- reduce the amount of operations
What to change
| Ticket | Status | Resolution | Summary | Component | Owner |
|---|---|---|---|---|---|
| #2708 | closed | rejected | Implement lazy loading for custom filters in new options page | User-Interface | agiammarchi |
| #6440 | closed | fixed | High CPU/memory usage when adding large number of custom filters | User-Interface | agiammarchi, greiner |
Attachments (0)
Change History (10)
comment:1 Changed on 03/06/2018 at 05:59:32 PM by greiner
- Cc wspee saroyanm agiammarchi added
- Description modified (diff)
comment:2 Changed on 03/06/2018 at 06:11:13 PM by greiner
- Blocked By 6440 added
comment:3 Changed on 03/06/2018 at 06:11:39 PM by greiner
- Blocked By 2708 added
comment:4 Changed on 03/06/2018 at 08:04:34 PM by mapx
- Cc mapx added
comment:6 in reply to: ↑ 5 Changed on 03/07/2018 at 01:53:24 PM by greiner
Replying to agiammarchi:
Making it a blocker shouldn't prevent us to ship #6440 a part, since there is already a codereview in place and no need for specifications and/or UX studies, am I correct?
Correct, the idea is to get the UI into a workable state with #6440 so that we can then work on further optimizations independently.
comment:7 Changed on 09/05/2019 at 05:48:36 PM by greiner
- Resolution set to fixed
- Status changed from new to closed
Closing this ticket because all subtickets are closed.
comment:8 Changed on 09/17/2019 at 07:26:42 AM by sheweedddd
spam
comment:9 Changed on 09/17/2019 at 07:30:03 AM by sheweedddd
spam
comment:10 Changed on 09/22/2019 at 10:48:49 AM by sheweedddd
spam
Just to clarify, #2708 is the infinite list scroll which we decided to not put into the current milestone since it's a way to big story, compared to #6440.
Making it a blocker shouldn't prevent us to ship #6440 a part, since there is already a codereview in place and no need for specifications and/or UX studies, am I correct?