sync: Render "fetching" vs "fetched but not scanned" cells separately #20
Conversation
|
Hmm, running this today I'm seeing some noticeable lag / slowdown in the TUI update pipeline that I think results from this PR. Gonna leave this PR unmerged for now and see if I can figure out where the issue is. |
src/commands/sync/defrag.rs
Outdated
| let cell = if self | ||
| .fetching_range | ||
| .as_ref() | ||
| .map(|range| range.contains(&cell_start) || range.contains(&(cell_end - 1))) | ||
| .unwrap_or(false) | ||
| .fetching_set | ||
| .iter() | ||
| .any(|h| (cell_start..cell_end).contains(h)) | ||
| { | ||
| Some(("↓", Color::Magenta)) | ||
| } else if self | ||
| .fetched_set | ||
| .iter() | ||
| .any(|h| (cell_start..cell_end).contains(h)) | ||
| { | ||
| Some((" ", Color::Magenta)) |
There was a problem hiding this comment.
Figured it out: the slowdown was due to switching from storing fetching_range as a Range to using a BTreeSet. The latter is what we functionally need, but it was too slow for how we were using it, and that was slowing down this part of the render loop (deciding what colour to mark a cell). The effect flew under the radar for small TUI sizes, but with large sizes there were many more cells to check, so the effect became noticeable. That in turn caused the Action queue to back up, which eventually caused all other queue actions to slow down as well (like responding to shutdown requests).
I'm fixing this by switching to a RoaringBitmap (from the roaring crate), which has the same functionality but much better performance.
str4d
force-pushed
the
defrag-refine-fetching
branch
from
6186363 to
519101f
Compare
|
Force-pushed to fix performance problems. |
No description provided.