Reduce delay when loading job details panel

RESOLVED WORKSFORME

Status

Tree Management
Treeherder
P4
normal
RESOLVED WORKSFORME
3 years ago
2 years ago

People

(Reporter: emorley, Unassigned)

Tracking

(Blocks: 1 bug, {perf, regression})

Details

(Reporter)

Description

3 years ago
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?
(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

3 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 :-)
(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

3 years ago
Blocks: 1059368
(Reporter)

Updated

3 years ago
Priority: P2 → P1
(Reporter)

Updated

3 years ago
Blocks: 1067846
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

3 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

3 years ago
(In reply to Ed Morley [:edmorley] from comment #5)
> It's slightly better, 

-> P2.
Priority: P1 → P2
(Reporter)

Updated

3 years ago
No longer blocks: 1059400
Keywords: regression
(Reporter)

Updated

3 years ago
Priority: P2 → P3
(Reporter)

Updated

3 years ago
Priority: P3 → P4
(Reporter)

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.