PSA - both sides of an if on your page get evaluated and sent to the browser on load

All - just a PSA - we had a page with several complex web blocks under if's on page itself.  Via conditions set in prep only 1 of the if's should be true.  We noticed a long load time unless we deleted all the if's except for the one we knew was going to be true.  In any other language I have worked with if you have an if you expect only one side of the if to be used and the other to be disregarded.  Started a tech support ticket and was informed that this is expected behavior and in fact both sides of every if on the page itself do get evaluated and while not rendered in html the code is evaluated/sent which slows down load time.  OutSystems tech support stated this is expected behavior and the system is operating as expected.  I highly disagree with this as I expect if you have an if, only one side of it should take up resources on load.  I plan to start an idea request on this shortly but wanted to let everyone know about this feature.

Hi Jason,

Are you describing short circuit evaluation? While plenty of languages make use of it, this isn't a guarantee in every language.

The Outsystems documentation only makes assurances regarding the HTML content, and not the evaluation process:

https://success.outsystems.com/Documentation/11/Reference/OutSystems_Language/Web_Interfaces/Designing_Screens/If_Widget

To be honest I've never had any issues with this.

Afonse,

I have never heard of short circuit evaluation so not sure if this is the same thing.  I guess from my viewpoint if something is under an if I am not expecting resources on load to be spent on the branch of the if that is not being shown.  I agree on the documentation, but doesn't mean it is the best way to do it.  Yes, most applications will not see a difference but I would prefer it to only evaluate one side.

Jason, I don't think that's true at all.

The if widget on a screen will only evaluate one of its branches. There are no exceptions to this.

What seems to be happening on your case (and I'm basing this on your other thread) is that the if widget held several web blocks on each branch. This indeed can have a couple effects, not related to evaluation.


First, the ASPX pages rely on a tree of controls. This is like the backbone of the screen. The if widget, for example, will be one control with two children - the True branch, and the False branch, each being its own control. Each branch will have other descendants as well. Note that this tree will always have both branches - regardless of the value of the if condition. If your if widget has a complex control tree on both branches, it will take longer to load the tree - and it will take longer in tree traversals as well.

Second, the screen needs to determine the stylesheets of all web blocks that can possibly be rendered. The screen includes all of those stylesheets, even if the web block is not rendered on page load. The reason is to avoid styles being added to the screen after page load.

Third, web blocks that are not rendered still need to keep track of their viewstate. You can understand it more easily by thinking about a web block that holds a button and a local variable storing a click count. If you render this web block and click the button twice, the local variable will have the value of 2. If you then use an ajax refresh to hide this web block inside an if, the variable still needs to retain its value of 2. If you then refresh it again to show it, it should display the value of 2. This value must be kept in the viewstate, even though the web block was not rendered during some stages of the screen lifecycle.


In none of these examples the web blocks were "evaluated". The preparation was not executed, queries were not executed, widgets were not rendered. But you can probably now understand why having content in the invisible branch still impacts the screen performance.

Now, usually these effects are quite small. My guess is that you either have lots of web blocks inside those ifs, or each of your web blocks have a large widget tree.


Another effect (and this one is considerable, but only occurs during the first access to the screen) is that the ASCX files from web blocks need to be compiled. These files are compiled even before evaluating the if conditions, so the ASP.NET compiler will choose to compile both branches.

leonardo.fernandes wrote:

Jason, I don't think that's true at all.

The if widget on a screen will only evaluate one of its branches. There are no exceptions to this.

What seems to be happening on your case (and I'm basing this on your other thread) is that the if widget held several web blocks on each branch. This indeed can have a couple effects, not related to evaluation.


First, the ASPX pages rely on a tree of controls. This is like the backbone of the screen. The if widget, for example, will be one control with two children - the True branch, and the False branch, each being its own control. Each branch will have other descendants as well. Note that this tree will always have both branches - regardless of the value of the if condition. If your if widget has a complex control tree on both branches, it will take longer to load the tree - and it will take longer in tree traversals as well.

Second, the screen needs to determine the stylesheets of all web blocks that can possibly be rendered. The screen includes all of those stylesheets, even if the web block is not rendered on page load. The reason is to avoid styles being added to the screen after page load.

Third, web blocks that are not rendered still need to keep track of their viewstate. You can understand it more easily by thinking about a web block that holds a button and a local variable storing a click count. If you render this web block and click the button twice, the local variable will have the value of 2. If you then use an ajax refresh to hide this web block inside an if, the variable still needs to retain its value of 2. If you then refresh it again to show it, it should display the value of 2. This value must be kept in the viewstate, even though the web block was not rendered during some stages of the screen lifecycle.


In none of these examples the web blocks were "evaluated". The preparation was not executed, queries were not executed, widgets were not rendered. But you can probably now understand why having content in the invisible branch still impacts the screen performance.

Now, usually these effects are quite small. My guess is that you either have lots of web blocks inside those ifs, or each of your web blocks have a large widget tree.


Another effect (and this one is considerable, but only occurs during the first access to the screen) is that the ASCX files from web blocks need to be compiled. These files are compiled even before evaluating the if conditions, so the ASP.NET compiler will choose to compile both branches.

Leonardo,

You are correct that there are alot of web blocks under the "false" side of the if and that is what is causing this long load.  I guess when we made it we expected if its not on the true side of the if it would not take up resources.  It looks like we have found a work around for this to have one page with "many" different blocks on it where only one is shown at a time by using the RenderWebBlock action.


I understand, and I believe you when you say you've found a case where this is problematic. Let us know when you've created the idea, and if it's not too inconvenient, consider adding a code example.

Edit: thank you for the explanation about what's happening in the background, Leonardo.

Afonso Carvalho wrote:

I understand, and I believe you when you say you've found a case where this is problematic. Let us know when you've created the idea, and if it's not too inconvenient, consider adding a code example.

Hopefully Outsystems staff can comment on the rationale behind the implementation.

Would you consider going from 9 second load with all the possible blocks for the page view there vs deleting all the other blocks and that dropping to 2 second load time problematic? :D

The issue is that where I work we are not supposed to post any code we have written as its property of that group.  We tried to make a sample espace for tech support but as you mentioned unless its a very complicated set of blocks you don't really see too much of a load time change.

Not sure if direct link will work but here is the idea: https://www.outsystems.com/forums/discussion/48848/psa-both-sides-of-an-if-on-your-page-get-evaluated-and-sent-to-the-browser-on-l/