Debugging slowness in app + How temporary variable updates happen

Discussion
1

I have been working on a retool app for the past month and its has gotten pretty big.
All the features are built but now I am facing some performance issues, so was just trying to understand where I can speed things up.

More or less this is my basic setup

  1. I load data from api

  2. Store the data in a temporary variable "t1"

  3. Have a retool table in UI that's showing data from this temporary table called "t1"

  4. When a cell of the table is updated
    a. I run a js query on "Change cell" event, that will get the changes made by user via "changesetArray". Then I will determine new values for other rows of the table (business logic -> changing a cell value can cause changes in cells of other rows)
    b. The js query in (a) then calls another js query with the new data as additional scope. This js query then does "t1.setValue(newTableRows)" to update the temporary variable with the updated data
    c. do table.clearChangeSetArray() as no changes in table anymore

  5. There are many transformers whose value update depending on the value of "t1"

  6. There is a button on UI called save changes that when clicked updates all backend database with the new table values

The slowness is in step 4.
After I change a cell value, the cell value changes immediately in UI, but changes in the other dependent row takes 1-2 seconds to reflect.
Also when I change many cell values in quick succession (still 1 at a time though) via ui, the cell updates don't work properly and sometimes updates made in row 5 cell 5 is reflected in row 5 cell 4. This doesn't happen when i change a cell, wait 1-2 sec and then change another cell

The one thing i don't understand is why do i need to await when making a call to js query (await jsQuery.trigger()) and again await when doing setValue (await t1.seltValue()). Isn't all this running in browser? Why is await needed in this case? Does this mean they get executed in server (rather than in browser) and that's why the delay?

Althouh my set up may not be very optimised but since my table only has 1500 records, it's too less to cause any noticable delay
This has been bugging me for a while and unsure how to proceed further.

2

i dont think i can answer everything here but maybe i can exolain the await stuff. it might be easier to think of this in reverse though. start ing with the query being triggered. this comes down to an OOP viewpoint, where 1 function should have 1 responsibility. here, we're looking at a query as a function. its job is simply to make the query. it doesnt need to care about who/what/where ot was called from and it doesnt care if the caller needs a response. whatever called the finction should be the one to decide what to do with the response. as programmers we have 2 options.... either we care about the response because we need to process it, or we dont care at all what happens after we call it. in the later case, there's no reason to wait around and see what happens, we can light the fuse and walk away. well, while we walk away from the fuse why not light another one? we dont care about the first fuse, so theres no reason to wait around to light the 2nd. the same thing happens here, think of the query as a fuse. in some situations you need to wait and see what happens, more often than not you don't need to but its safer to wait, so we do it anyway.

no, this doesnt mean its ran on the server. its actually the opposite. the server spits out code and the browser 'decodes' it w the local JVM (Java Virtual Machine). this is how java and javascript are both os/env agnostic.

you can honestly think of it as spinning up a background thread to make a query while the main thread continues on with its work.... and im gonna confuse you for a sec (if i havent already) to say that this is not how javascript does it. its just the easiest way to visualize it as technically javascript is single-threaded but thats not i.portant right now :sweat_smile:

so should you always use await when you call .trigger()? if after you use .trigger() your codes, or any quries called from the same code block before returning, needs to use the results then yes, use await. this might be one of those things thats easier to grasp with a pucture, if so just let me know and ill happily bust out my programmer art lol.

sorry for all the typos, im on my phone and as for helpi g out w speeding things up... from what youve described the queries are creating a bottleneck on the app. Id suggest extracting that table from step 4 and the queries it needs to create a module. afterwards you can insert the module and itll have its own little space to do its processing while the main app can continue on.

the cell updating thing i think its a side effect of using so many onSuccess events chained together. id guess after recieving so many events either something gets confused or more likely it can only qeue up so many events before it starts to cancel the oldest assuming its been invalidated.

i just realized i ended up trying to answer everything anyway :upside_down_face:.