Closed
Bug 1062398
Opened 10 years ago
Closed 9 years ago
Reduce delay when loading job details panel
Categories
(Tree Management :: Treeherder, defect, P4)
Tree Management
Treeherder
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: emorley, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf, regression)
Bug 1059283 fixed the issue there by adding a delay using setTimeout (https://github.com/mozilla/treeherder-ui/commit/040775a1978e0ee36e6db43ba0f9021a3aba1938). This delay is only 200ms, but is still noticeable (albeit less annoying than the original issue, so fixing this is less urgent). Perhaps we can try reducing is to 100ms or something?
Comment 1•10 years ago
|
||
(In reply to Ed Morley [:edmorley] from comment #0) > Bug 1059283 fixed the issue there by adding a delay using setTimeout > (https://github.com/mozilla/treeherder-ui/commit/ > 040775a1978e0ee36e6db43ba0f9021a3aba1938). > > This delay is only 200ms, but is still noticeable (albeit less annoying than > the original issue, so fixing this is less urgent). > > Perhaps we can try reducing is to 100ms or something? I experimented with 100ms before I landed this. I found that it usually wasn't enough time to avoid the load when rapidly cycling through jobs, at least on my machine and my 30-something reflexes. If the delay is really annoying, I think we should probably try to find some other way of fixing that than using the timeout (could we get the data from a websocket that we keep open to reduce latency?), as I doubt we'll ever find a value that will make everyone happy.
Reporter | ||
Comment 2•10 years ago
|
||
This delay is most noticeable when scrolling through jobs that have already been loaded once & so should have the api response in-memory. Also I would say that it's fairly common even when scrolling through failures, that one will want to revisit all of them at some point (to classify them all, once you've taken a quick look) - so loading the API data isn't necessarily a waste (presuming we keep it in memory up to a point), and as such, perhaps only cancelling the UI update (and not the API data request) is the best way to improve this? Anyway happy to leave this until later :-)
Comment 3•10 years ago
|
||
(In reply to Ed Morley [:edmorley] from comment #2) > and as such, perhaps > only cancelling the UI update (and not the API data request) is the best way > to improve this? Yes, we could certainly try something like that! Maybe a short delay before starting the load, then a longer delay before showing the progress.
Reporter | ||
Updated•10 years ago
|
Priority: P2 → P1
Comment 4•10 years ago
|
||
I recently changed the way the job details get updated, I'm wondering if this bug is still valid?
Flags: needinfo?(emorley)
Reporter | ||
Comment 5•10 years ago
|
||
(In reply to Mauro Doglio [:mdoglio] from comment #4) > I recently changed the way the job details get updated, I'm wondering if > this bug is still valid? It's slightly better, but we're still using the setTimeout: https://github.com/mozilla/treeherder-ui/blob/4cf5891249c0053e6fda8cc3cae653de969f5765/webapp/app/js/directives/clonejobs.js#L194 Which could be tweaked to speed things up more hopefully? :-)
Flags: needinfo?(emorley)
Reporter | ||
Comment 6•10 years ago
|
||
(In reply to Ed Morley [:edmorley] from comment #5) > It's slightly better, -> P2.
Priority: P1 → P2
Reporter | ||
Updated•10 years ago
|
No longer blocks: treeherder-dev-transition
Keywords: regression
Reporter | ||
Updated•9 years ago
|
Priority: P2 → P3
Reporter | ||
Updated•9 years ago
|
Priority: P3 → P4
Reporter | ||
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•