Increase performance when using api call to parent

I often use a parent entity as a library entity to use its data in a child.
This however slows the parametrisation a lot. About 1.6-2 secs between each change in the parametrisation without any output field.

For instance a table input field gets data from the parent entity as shown below:



Is there a way to increase its velocity or do this Library Parent Entity principle in a smarter way?

Hi Johan, the API from the api_v1 module includes caching of api calls which means you do not need to add logic yourself as you do in the example. See the section about callback functions here: Share data between entities using the API | VIKTOR Documentation

So in your case, the actual API call to the Project params is only executed once and will be re-used within every callback automatically (within the same job).

I see you mention a parametrization of about 2 seconds, so I am curious to see how much this is when you disable the table. Can you try this out?

Hi Kevin,

I am using api_v1. I removed all other option/api fields at parametrization level.
The method entity.last_saved_params is the biggest. About 0.9-1.6 seconds.
The API call itself isn’t that slow at all.
So it is cached with the tables also.

Changing something at projectlevel takes about 20-30ms (parametrization)

def get_params(entity: Entity):
    return entity.last_saved_params

def get_id(entity: Entity):

def _get_footing_options(params: Munch, entity_id: int, **kwargs) -> List[str]:
    parent = API().get_entity(entity_id).parent()
    # return [str(x) for x in range(5)]

    project = ProjectParams(get_params(parent), get_id(parent))

    return [ for footing in project.footing_table]

2021-12-16 13:38:03.455 INFO : Job received - uid: 17335 - EntityType: FieldFoundation - function: parametrization
Function ‘get_params’ executed in 1.2839s
Function ‘get_id’ executed in 0.0000s
Function ‘_get_footing_options’ executed in 1.2852s
2021-12-16 13:38:04.761 INFO : Job completed in 1291ms

If i enable the other tables again, you can see the first time is the worst (afterwards it gets cached)


A single API call should take about 200ms, which means that another second in _get_footing_options is caused by the remaining logic. Can you confirm?

Well I created a Decorator once to measure the time of a function. Using only entity.last_saved_params takes about .1.3 seconds.

The other logic fills the remaining time, which is only about 0.1 seconds.

def get_params(entity: Entity):
    return entity.last_saved_params

If I however run first instead of entity.last_saved_params. The id method takes longer.
So my gues is that the first time I activate the find data of a given entity_id takes the longest, I can’t really find out why though.

Ah ye now I see. The api calls are performed in a lazy way, which means that the actual api call is performed when the data needs to be retrieved. So API().get_entity(entity_id).parent() does not actually trigger an api call, but when you need the entity_id or the params, the api call will be performed on the first call. That’s why you will notice the difference when changing the order.

Anyway, what is the size of the parametrization of the parent entity? And how many rows do the tables have?

The response is about 25kB, after updating layout about 960 lines.
It contains like 8 tables, the amount of rows vary, in this case some tables contain 30 lines, most between 3-10.

The parametrization at project level only takes about 30ms to reload though.

Does this behavior also happens on the deployed live app, or is this only in a development environment?