Get_id() is a remote call?

Anvil Q&A
1

Hello all,

I am doing some performance tuning on one of my anvil apps, and I notice that calling get_id() on a client side Row object was triggering an RPC call.

I was wondering why that was?

I had a look at the web socket traffic and noticed the ID was being sent to the client during the initial server side call.

Is there a way I can get the ID without a network round trip?

2

Yes, there is! The current workaround is to call:

anvil._get_live_object_id(row)

This returns the same as row.get_id(), but is currently faster. (You’ll be pleased to hear there’s work underway to remove that extra round-trip.)

4 Likes
3

Any progress on this?

We have been able to use row._spec[“id”] to retrieve the ID and greatly improve speed. Why not include id as a property or a key in getitem?

4

Using row objects on the client side is great during prototyping, but when it’s time to look at the speed I never pass the row itself. Instead I create a dictionary on the server side, adding the row id if required, and return it to the client. So I am sure that the client will never contact the server.

5

That’s what we do too but have noticed the get_id requires the server to talk to the db (which introduces lag even on the serverside). (At least i think so)

6

Oh, then these can be two different problems. The original post explicitly mentioned “on a client side Row object”.

(If you don’t see an answer by tomorrow, I would create a new post, just to make sure the powers that be pay attention to it.)

7

@woodpav is right – get_id() still costs a few ms, even on the server.

We are definitely working on this one – there’s a lot of architectural preparation needed before we can make the shift, but once we’ve got it in place we’ll have a lot more elbow room to improve data table performance.

(Comparison: It’s like implementing hierarchical form packages on the client side. The actual UI switch was pretty straightforward, but preparing the Python interpreter, designer, form-navigation system etc to deal with it – and backwards-compatibly too – was the 90% of the iceberg that lay under the surface. Likewise, once we’ve done this internal re-architecture, making get_id() fast is going to be trivial – a two-line change – but we’re still working below the waterline right now, so all you’re seeing is the bubbles :slight_smile: )

2 Likes