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.

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

Prefetching rows from remote source #92

Closed
zalmane opened this issue Sep 29, 2020 · 3 comments
Closed

Prefetching rows from remote source #92

zalmane opened this issue Sep 29, 2020 · 3 comments
Labels
question Questions about use, potential features, or improvements

Comments

@zalmane
Copy link

zalmane commented Sep 29, 2020

Is there a way to prefetch rows from a remote source?
It seems that setting setDataListener gets called whenever the viewport changes. When scrolling this generates a lot of calls to the server. What is the best way to implement a caching mechanism to load data in pages (e.g. load 100 rows instead of just the 25 of the viewport) and have the table generate a call only when needed, or when approaching the edge of the prefetched data?

@texodus
Copy link
Member

texodus commented Oct 5, 2020

regular-table does not cache/keep any data, even for just the visible viewport, once rendered this data is discarded. This is by design, and preserves proper separation from the data model. If you have a specific prefetch strategy in mind, it is trivial to implement a cache pattern within a setDataListener() callback data model, something like so:

async function dataListener(x0, y0, x1, y1) {
    if (!cache.has(x0, y0, x1, y1)) {
        const data = await getDataFromServer(...embiggenViewport(x0, y0, x1, y1));
        cache.set(x0, y0, data);
    }    
    return cache.get(x0, y0, x1, y1);
}

Future renders will block until a page request to this callback is complete, so you can trade off page-boundary for intra-cache performance as desired.

If you are interested in a more fully-featured data model, rather than the bring-your-own approach of regular-table, check out perspective, a complete WebAssembly data model and query engine for regular-table

@zalmane
Copy link
Author

zalmane commented Oct 5, 2020

Thank you for your repsonse! Perspective is great and I was actually asking in that regard. It seems that the Perspective dataListener in case of a remote view reloads the viewed records from the remote server which causes a lot of roundtrip data sent over the wire. I was looking into the best way to implement such caching with Perspective's remote view capabilities.
I was asking on this repo since it seems the dataListener implementation for Perpsective resides here.
Does this functionality already exist within Perspective?
Any pointers on implementation would be appreciated so I can try to produce a PR.

@texodus
Copy link
Member

texodus commented Oct 5, 2020

No, perspective-python's virtual mode does not do this; scroll performance is substantially better without it for the reason stated below. However, it is much more common to run perspective both on the server and client (via the perspective.js WebAssembly library), in which case the entire data set is downloaded via Apache Arrow to the browser and loaded locally where scroll "roundtrip" is not an issue.

It seems that the Perspective dataListener in case of a remote view reloads the viewed records from the remote server which causes a lot of roundtrip data sent over the wire.

All virtual data models do this, even if you increase the "page size". I think you may misunderstand how regular-table's scrolling works, it does not make a request for every scroll row; rather, it fires a scroll repaint at the current scroll position at the moment the previous render frame is complete, which may be many thousands of rows after the previous frame, or perhaps before (or diagonally!), depending on where the user has scrolled. Doing nothing other than increasing the page size makes your request 1/N as frequent but block for N times a long, except you no longer can make requests for the next draw page while rendering the previous one, leading to overall lower average scroll frame rate.

@texodus texodus closed this as completed Oct 5, 2020
@timkpaine timkpaine added the question Questions about use, potential features, or improvements label Oct 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Questions about use, potential features, or improvements
Projects
None yet
Development

No branches or pull requests

3 participants