Referencing a Form field is very, very slow

Wappler General How To
#1

I am trying to do some simple optimisation on different parts of this site. One area I can make a difference is the the SQL statements, which takes a bit of thought and working out.

The area I can’t make any progress on is referencing Form Input fields. So in this simple example I want the 'value' of the selected Select field to appear further down the page. In reality this will be used for a calculation but for now I have striped it back to basics because this seems to be where the delay is.

So on this page, a multi-step form, I have 'Repair Status' which is pre-selected at '41 No Estimate Submitted at Time of Inspection' and I want the '41' to appear in the Input field below. OK, this works BUT very, very slowly. In fact so slowly that the user can miss this and move on without reacting to it. I’ll not bother with that detail as it is irrelevant at this time.

image
image508×522 34.6 KB

So here is the DevTools Elements tab showing the code

image
image715×133 11 KB

And here is a simple gif showing the delay.

The gif shows me on 'Step 9. Status' of the multi-step form, then doing a simple Ctrl-F5 refresh which takes me to 'Step 1. Set-up', I click on 'Step 9' and 'Show' the Input field where I want the result. It starts out blank and we wait for the '41' to show.

Wappler - slow calculation
Wappler - slow calculation1192×626 351 KB

As you can see, this seems to take forever and yet the '41' is already select above and the reference to it is as simple as '{{inp_driv_rep_status.value}}'

Is this a BUG?
What can I do to make it instant?

#2

Does anyone have the same issues?
Can you recreate the same thing?

#3

I’ve certainly experienced the same thing - but not with Wappler. I would go through each expression on which the problem one is dependent, and see if there is a bottleneck at some point. If you find the problem, consider different ways to resolve it - eg accessing the data in a different way or perhaps denormalising some data.

#4

Have encountered such performance issues with increase in number of expressions on page. Usually with repeats.
One of the way to instants reduce memory consumption is to use conditional regions instead of show/hide. With CR, HTML does not even render, hence there are no additional hidden fields where DMX is dynamically parsing expressions.

Once I had an issue with select2 library. Just updating it to a newer version fixed the issue for me. So maybe look at the external scripts you are using.

Overall, in my experience, you can somewhat manage the performance and improve it, but its not always upto the mark if the page size and dynamic stuff are a lot on the page.
Patrick had updated the DMX/AppConnect logic once sometime ago, which drastically improved it. He is the best guy to help you improve this.

#5

Hi there @UKRiggers… which version of Wappler are you using?
Did the speed get slower after you upgraded to a specific version of Wappler?
I’m experiencing some very slow behaviour in my app too… am investigating it this afternoon. I’ll keep you updated on what I find.

#6

Hi @sid interesting comment about the Show/Hide vs Conditional Region. It makes sense now I come to think about it.

There were about 50 Show/Hide on this page, changed them all to Conditional Region but no noticeable improvement.

What I don’t understand is why referencing something that exists takes so long. Surely ‘{{inp_driv_rep_status.value}}’ should return '41' straight away? But it doesn’t.

image
image508×522 33.7 KB

#7

Hi @Antony, I am on 3.5.5 and this behaviour has been the same for quite some time.

#8

Are you sure? There is instant performance increase everytime I have used it.
Maybe recheck if the conditions are set correctly or not.

The reason why it takes so long is that AppConnect/DMX keeps “scanning” all the bindings and keeps “parsing” all expressions every few ms.
If there is some expression in a repeat, that takes up more time per cycle.
(by ALL, i mean the ones that are relevant)
To see such behaviour, try setting an incorrect formatter in an expression inside repeat and your console will be flooded with warnings.
One would assume that expressions get parsed once when loaded, and later when any variable involved is updated. But, that is not how DMX works. It repeatedly runs JS to evaluate such expressions.

Hence, for you its one select drop down, for dmx its an additional event over everything its doing already.

Disclaimer: This is my lay-man understanding of this stuff. I might be wrong.

#9

The biggest performance issues I know of with App Connect are repeaters and big datasets. Is the form field that is slow nested inside one or more repeaters?

Conditional regions can help, if the region is hidden it doesn’t update the children while it does update children with a simple show/hide. This can improve performance a lot sometimes if it has a lot of components in it.

For debugging you can use devtools. In the performance tab you can record the slow behavior and try to figure out what is causing it. Look for long running scripts or functions that are called very often.

#10

Thanks for your input @patrick!

I have a major problem with a large table of data. Once I start trying to display it, my entire app’s interactive performance grinds to a snails pace. It is completely unusable for my clients… :frowning:

Would you be willing to take a look and tell me how I can improve the speed? It may be there is something you can add/change in Wappler, or maybe I need to build it a different way… I don’t mind going lower level and using some JS if that is what I need to do!

If you are able to take a look, I’ll pm you all the login details.

Many thanks,
Antony.

#11

Sure I can have a look, will do that tomorrow if you send me the details.

#12

@sid I jsut tested this out, I put a basic conditional region on the page in place of a simple show/hide - and the HTML does infact render. I’m on NodeJS - I don’t know if that makes a difference.

#13

Html renders even when condition is false? :thinking:
It should just show a blank div.
And when condition is true, it should render the child elements.

#14

Yep renders even when false, which I thought was a bit odd after your comment…

#15

Do you have a link to the page where this is happenning?
Or maybe try running the condition in console to see if its actually false or not.

I haven’t seen this at all. And have used it in Node as well.

#16

Just triple checked - you made me doubt myself! :sweat_smile:

I have a condition based on an integer in DB.

Conditional region should display if integer is 1 or more.
Conditional region should NOT display if integer is less than 1.

Confirmed that in the console the integer value being checked is 1. The correct conditional region is displaying. The conditional region that should NOT display is not displayed on the page.

View Source > The conditional region that should NOT display renders the full HTML in the View Source.

#17

Oh. You are looking at the wrong place. Conditional region just hides HTML from page on client side.
The view source you see is what server sent to the client.
Look in the element part of dev tools. You should see a blank div.

To hide content on view source level would mean that server should not send that part of code. And that cannot be done without making a request to the server. The CR works on client side, managing DOM, reducing memory usage without need of server calls.

1 Like
#18

got it! Thanks for the clarification sid.

#19

@patrick… is there any way to detect in Wappler that the data is still rendering so that we can display a spinner of some kind?

#20

This feels like a trade-off… I’ve experimented with conditional regions for turning on and off the display of different “content heavy” screens on my app…

… and while they save resources when a screen isn’t being viewed, they also mean that the entire display has to be re-created when that screen is re-visited, resulting in a delay each time you go to that screen with the same dataset. (which will be a common action for my users).

(I hope that makes sense!).