Closed Bug 1062398 Opened 10 years ago Closed 9 years ago

Reduce delay when loading job details panel

Categories

(Tree Management :: Treeherder, defect, P4)

defect

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?
(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.
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.
Blocks: 1059368
Priority: P2 → P1
Blocks: 1067846
I recently changed the way the job details get updated, I'm wondering if this bug is still valid?
Flags: needinfo?(emorley)
(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)
(In reply to Ed Morley [:edmorley] from comment #5)
> It's slightly better, 

-> P2.
Priority: P1 → P2
No longer blocks: treeherder-dev-transition
Keywords: regression
Priority: P2 → P3
Priority: P3 → P4
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.