Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Optimise UI performance when dragging TMA tracks #4729

Open
IanMayo opened this issue Jan 17, 2020 · 6 comments · May be fixed by #4789
Open

Optimise UI performance when dragging TMA tracks #4729

IanMayo opened this issue Jan 17, 2020 · 6 comments · May be fixed by #4789
Assignees
@saulhidalgoaular

Comments

@IanMayo
Copy link
Member

IanMayo commented Jan 17, 2020 •
edited

An analyst is working on a really large dataset:

  • 8 day ownship track at 15 minute positions (~66k items)
  • 3 hours of sensor data, with 300 sensor cuts
  • TMA solution for whole period of sensor data, with 18 solutions, plus infills

When he drags the TMA solution, each redraw of the Stacked Dots takes around 0.1 seconds (very roughly). This isn't interactive enough to keep up with his mouse movements.

We suspect the time lag is because of the volume of processing being conducted, maybe in these areas:

  • time taken to get ownship position at time of sensor cut
  • number of values recalculated
  • number of items re-plotted in JFreeChart on the stacked dots

Once Ian has produced a sample dataset for this issue, we can start considering/identifying bottlenecks.

One suspicion is that we're re-calculating/re-rendering more data than is necessary. When a single leg of data is being dragged, we only have to re-do the points for that leg - the values for the other legs are unchanged.

In the scenario in question we have 18 legs (call it 20). If we only re-calculated the data for the current leg, that would only take 5% (1/20) of the time that it's currently taking.

See the video below, of a much simpler scenario:
Recording of track dragging

A large sample data-file is attached.
8_day_track_with_sensor.dpf.zip
@saulhidalgoaular saulhidalgoaular self-assigned this Jan 19, 2020
@IanMayo
Copy link
Member Author

IanMayo commented Jan 20, 2020 •
edited

@saulhidalgoaular - here's a second sample file. In it I've broken up the TMA solution, and generated infills.

8_day_track_with_sensor_and_TMA_infills.dpf.zip

The performance drop happened after I generated the infills. This almost certainly looks like the cause of the error.

I welcome you profiling the update. Maybe each DynamicInfillSegment should cache the start/end points of the previous leg. If these values haven't updated, then the infill doesn't need to recalculate.

But, let's see how your investigation goes.

@saulhidalgoaular saulhidalgoaular mentioned this issue Jan 20, 2020
Closed
@IanMayo IanMayo mentioned this issue Jan 20, 2020
Merged
@IanMayo
Copy link
Member Author

IanMayo commented Jan 20, 2020 •
edited

@saulhidalgoaular - you've solved the worst bottleneck in this code. I'd like you to carry on please, and analyse where we're losing performance through excessive calls to StackedDotHelper.updateStackedDots. Some operations will require updates of the stacked, dots, but I don't think we need than one call per new mouseDrag callback from the UI.

I can produce a new sample data file that contains more sensor data. It would be great if Debrief could still be reactive with 24 hours of sensor data in the 8 day period.

Aah, but I appreciate we can only go so far with the current algorithms. At some point I expect we're going to have to refactor how we handle mouse dragging, and how/where we update the contents of the stacked dots (Bearing Residuals plot).

@helenayele
Copy link
Collaborator

We still need to improve the speed , I tried with 8_day_track_with_sensor_and_TMA_infills.dpf.zip data and it is still slow.
Image from Gyazo

1 similar comment
@helenayele
Copy link
Collaborator

We still need to improve the speed , I tried with 8_day_track_with_sensor_and_TMA_infills.dpf.zip data and it is still slow.
Image from Gyazo

@IanMayo
Copy link
Member Author

IanMayo commented Feb 3, 2020

@helenayele - when you get chance, could you retest the drag-track performance with that 8-day file?

@helenayele
Copy link
Collaborator

Okay , Now I tried to test on develop branch, again the speed is not that much satisfactory , see how it behaves in this video:
https://screencast-o-matic.com/watch/cYneInwlqk

@saulhidalgoaular saulhidalgoaular linked a pull request Feb 13, 2020 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@saulhidalgoaular saulhidalgoaular

Labels
None yet
Projects
None yet
Milestone
No milestone
3 participants
@IanMayo @saulhidalgoaular @helenayele