Partial updates trigger full rows to be sent?

[nickroci]

I have quite a wide data set so was looking at doing some optimisation and not sending unchanged data at every tick. However it seems like perspective is sending out full rows even on partial updates? Is this right, is there any way around it I've missed?

import perspective
import pyarrow as pa

table = perspective.Table({"index": str, "num": int, "static": int}, index='index')
table.update({"index": ["b", "c"], "num": [0, 1], "static": [0, 1]})
 
manager = perspective.PerspectiveManager()
manager.host_table('test', table)
session = manager.new_session()

def post(message, binary=False):
    # capture manager output
    if binary:
        print("Update:", pa.Table.from_batches(pa.RecordBatchStreamReader(message)).column("num").to_pylist())

# simulate a ws client
session.process('{"id":-1,"cmd":"init"}', post)
session.process('{"cmd": "view", "view_name": "0.35865966016938167", "table_name": "test", "id": 1}', post)
session.process('{"cmd": "table_method", "name": "test", "method": "get_index", "args": [], "subscribe": false, "id": 2}', post)
session.process('{"cmd":"view_method","name":"0.35865966016938167","method":"to_arrow","args":[],"subscribe":false,"id":3}', post)
session.process('{"cmd":"view_method","name":"0.35865966016938167","method":"on_update","args":[{"mode":"row"}],"subscribe":true,"callback_id":1,"id":4}', post)

# update with the same data
table.update({"index": ["b", "c"], "num": [0, 1], "static": [0, 1]})
# update with partial data
table.update({"index": ["b", "c"], "static": [0, 1]})

>>> 

Update: [0, 1]
Update: [0, 1]
Update: [0, 1] # shouldn't have this col as it's not included in the update + hasn't changed?

[texodus]

Perspective used to have a "cells" update mode which did this, but in practice the measured performance was much worse in aggregate as for batches with many arbitrary column updates, we need to calculate which column/row combinations in the batch have updated rather than just re-using the existing Arrow schema and point-updating cells. This isn't a one-dimensional measure; a real-world use case we can measure performance on would help in understanding how to improve your specific performance criteria.

Unrelated, but should be noted the session API (and the perspective client/server API in general) is not public and should be considered an implementation detail (virtually guaranteed to break at some point). There is a perspective-python client available to simulate connections if you need it.

[nickroci]

To revive this and to distill what I posted below, an optimisation could be to send data for whole columns where there is any change, not per cell. Think this would work well when you are feeding in arrow data especially. I might have a crack at adding it as I currently have some frankenstein creation with two+ perspective managers feeding a single grid whilst merging in the ws feeds. Any pointers where to start or likelyhood of approval?

Thanks!

[nickroci]

Thanks for the details @texodus! Yes I wasn't 100 percent sure how much difference it would make. Guess it comes down to having a mixture of columns that don't update frequently at all but a few that do very frequently, if there are a lot of rows, columns (strings) and clients it starts adding up. Obviously there are only so many columns and rows a person can look at so limiting columns is one option, but then server view mode has a bit of lag which isn't ideal. Maybe a hybrid server view mode where you limit the columns that are sent from the server could work - something I'm looking at doing at the moment via a separate ui (setting a restricted set of columns on the server view).

For instance (not my actual project :)) maybe you wanted to build an ebay dashboard showing ticking prices, but then all the catagory data for each item, size, color, year, name, location etc etc. You know you are looking for shoes at the moment so only size, color and material matter, you select only those columns and price - do some ordering to find the shoes you want. You don't really want all the relatively static data updating for everything on each price change. Can deal with it through replication and load balancing but eventually makes the client lag a bit too.

Ill come up with a replication of what I mean, but seems like there isn't an easy solution, so restricting columns before getting to browser - putting it in shoe mode seems like the play.

[nickroci]

Looking at this again I guess I'm asking whether a "column" based update mode is possible, seems like it would be a good fit given the ability to do partial column based updates.

In the example below there is a table with a lot of unchanging columns, if there are lots of partial updates on price you can end up burning a lot of network/memory bandwidth on unnecessary updates. Like we know that category definitely wont need updating if we get a partial update only on price.

from perspective import Table

tbl = Table({"price": [1, 2, 3],
             "name": ["a", "b", "c"],
             "category": ["a", "b", "c"],
             "address": ["this might be a long string", "b", "c"],
             "size": ["a", "b", "c"],
             "height": ["a", "b", "c"],
             "width": ["a", "b", "c"],
             "length": ["a", "b", "c"],
             "width": ["a", "b", "c"],
             "color": ["a", "b", "c"],
             "rating": ["a", "b", "c"],
             "created": ["a", "b", "c"],
             "etc": ["a", "b", "c"],
             }, index="name")

tbl.update({"price": [7, 8], "name": ["a", "c"]})