Load the next scan each time a new scan is viewed #597
Conversation
Deploying with
|
| Latest commit: |
cad8a5b
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://c7c5a096.miqa.pages.dev |
| Branch Preview URL: | https://prefetch-ring.miqa.pages.dev |
|
We'll definitely want to evict old frame data out of the cache. IMO we can do that as soon as they move on to the next scan, or maybe we can keep one previous scan around. If we never evict them, we'll run up against memory limits. I haven't explored the code much; where is the cache data structure located? |
|
Maybe we can make the cache configurable at the Django settings level. For the annotation application, I expect to be moving back and forth between scans within an experiment so would like to keep all scans hot, but keeping a max of X (X=3? configurable?) experiments could allow us to flush while still minimizing wait time for users.
… On Sep 26, 2022, at 7:20 PM, Zach Mullen ***@***.***> wrote:
We'll definitely want to evict old frame data out of the cache. IMO we can do that as soon as they move on to the next scan, or maybe we can keep one previous scan around. If we never evict them, we'll run up against memory limits.
I haven't explored the code much; where is the cache data structure located?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
|
|
Thanks for the feedback @curtislisle . I didn't realize going backward and forward would be common -- in that case, a ring buffer makes even more sense as our cache structure. |
|
If it isn't too much trouble to implement a ring buffer, I like the
flexibility this brings. However, I don't think it is a critical need,
though, so we can prioritize accordingly. The Stanford application will be
forward only direction. I am planning for the annotation application to
examine multiple scans within an experiment simultaneously and may go
backwards occasionally.
…On Tue, Sep 27, 2022 at 8:07 AM Zach Mullen ***@***.***> wrote:
Thanks for the feedback @curtislisle <https://github.com/curtislisle> . I
didn't realize going backward and forward would be common -- in that case,
a ring buffer makes even more sense as our cache structure.
—
Reply to this email directly, view it on GitHub
<#597 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQNT5QPUZ625QWEBQYZCTLWALPO5ANCNFSM6AAAAAAQWELSYQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
The caching structure is complicated, but I think all functional parts are located in |
|
I think this merits adding a cache abstraction, i.e. functions to mediate adding to the cache that internally handle eviction, rather than direct access to the underlying data structure. |
|
I think this is a good idea, but I'm not sure how to begin. Do you have a similar example or would you mind working with me on this? |
|
From @zachmullen via Slack
Merging this and opening #598 to track further action |
Each time a new scan is requested, we queue loading all the frames in that scan, as well as all the frames in the next scan. If the scan has been loaded already, we skip the queue of that scan.
Finding the next scan to queue includes the first scan in the next experiment if the current scan is the last in its experiment.
From @zachmullen via Slack
How explicitly should we define the ring buffer? We previously didn't worry about clearing cached frames out as we moved along, perhaps we can trust the browser to manage the cleanup. Within this PR, I only implemented the addition of items to the buffer. Do we need to manually remove items?
I'd appreciate extra scrutiny on your review; I'm sure there's much to improve.