Platform
Learn
Community
Support
Partner Center
Sign up
or
Log in
logout
Account Settings
Profile
messages
Messages
logout
Logout
Platform
Home
Downloads
IPP
Licensing
Project Sizing
Learn
Training
Documentation
Evaluation Guide
What's New
Community
Home
Forums
Forge
Ideas
Members
Support
Partner Guide
Resources Library
Opportunities
Account Management
Sign up
or
Log in
Home
Forums
Forge
Ideas
Members
Dear ,
What would improve your OutSystems Community experience? Let us know by taking this 2-minute survey.
Pick up the survey
Community
›
Forums
›
Technology & Integration
Screen variables and memory management
Community
›
Forums
›
Technology & Integration
Screen variables and memory management
New Post
New Post
José Antunes
Posted on 2013-02-06
José Antunes
Rank: #520
Posted on 2013-02-06
Hi all!
I came across with some examples of screens that have variables that are only used in one of the screen actions. These variables should inside that screen action, because they use unnecessary memory, am I correct?
When the screen action flow ends its execution, the memory used in variables defined inside that action are freed, in opposition to screen variables, whose memory usage are freed only when the user exits that particular screen, right?
So, this kind of pattern wastes memory and should be avoided.
What is the behavior of the platform in these kind of patterns and how memory is managed in screens?
Thanks in advance!
Paulo Ramos
Posted on 2013-02-06
Paulo Ramos
Rank: #10
Posted on 2013-02-06
Solution
Hi José,
Your general thinking is correct. If your variable is only needed in one screen action, then declare it in the screen action, instead of the screen.
Note that screen variables are stored in the
viewstate
, which is exchanged between the browser and the server on every postback. So, they don't count significantly in terms of server memory - but they are relevant because as the viewstate size gets higher, it increases the page size, leading to a slower user experience (not because the server / app is slow but because more data has to be sent / loaded by the browser). That's also why you should avoid having recordlists as screen variables.
Solution
J.
mvp_badge
mvp_label
Posted on 2013-02-06
J.
mvp_badge
mvp_label
Rank: #7
Posted on 2013-02-06
Solution
Interesting and valuable information.
- Why does service studio does not generate a warning when you have screen/webblock -variables as recordlists ?
- what's the desired approach when you think you are in need of screen-variables of recordlists (say you get a RL from an action with a refresh)
Solution
Paulo Ramos
Posted on 2013-02-06
Paulo Ramos
Rank: #10
Posted on 2013-02-06
Solution
Statler & Waldorf
wrote:
Interesting and valuable information.
- Why does service studio does not generate a warning when you have screen/webblock -variables as recordlists ?
- what's the desired approach when you think you are in need of screen-variables of recordlists (say you get a RL from an action with a refresh)
Often you really need to have lists in the viewstate - when presenting an editable list, for example. What I meant was, it all cames down to data size. Although it's not usual, you can have more data in a text variable than in a list, so you have to keep in mind how the data will grow.
As a side note, if you have a simple query feeding a table/list records widget, the fields present in the viewstate are automatically optimized by the platform. So, if you don't use a particular field, the platform will not include it in the viewstate. This helps keeping its size reasonable.
Regarding the 2nd question, it should to be evaluated case by case... on some scenarios, you may even store that information in the server (database, session...), if it's too big for including it in the viewstate. You have to evaluate the impact in both bandwidth/latency and DB/frontend. For most simple cases, the viewstate is still probably the best option (it's a simple pattern, so it simplifies maintenance and avoids a penalty in the infrastructure capacity, specially if you have lots of concurrent users).
Solution
Evert van der Zalm
mvp_badge
mvp_label
Posted on 2013-02-06
Evert van der Zalm
mvp_badge
mvp_label
Rank: #56
Posted on 2013-02-06
Solution
Indeed some value information.
Sometimes use a RL as an variable to 'store' the retrieved data. On this way I can loop trough the RL (filling another RL) without needing to query the results again. Having this in mind can change my point of view in some of that cases.
Kind regards,
Evert
Solution
João Rosado
Posted on 2013-02-06
João Rosado
Rank: #13
Posted on 2013-02-06
Solution
Hi,
The reason there is no warning when using RL in screens/weblocks is because the optimizer does a lot of work to reduce the viewstate if possible.
For example, in the use case of using a variable as a local inside the screen action, if in all possible paths the variable is always written before it is read, then nothing goes to viewstate and the value will not be set in any other call/action.
Think of the optimizer as a shrondinger box. If you look inside you may get a different result. ;)
Regards,
João Rosado
Solution
J.
mvp_badge
mvp_label
Posted on 2013-02-08
J.
mvp_badge
mvp_label
Rank: #7
Posted on 2013-02-08
Solution
A follow-up question, why does OutSystems keep the viewstate in the page itself?
I know it's default for .NET but there are ways to keep the viewstate on server-side.
Solution
Quick Reply
attachment
Choose File
No file chosen
Submit
Login to reply
New Post
Available Forums
Technology & Integration
News and Announcements
Forge Discussions
Meta
Community Quick Guides
Usability
Installation Troubleshooting
Personal Environment Troubleshooting
Forum Notifications
Email Digest Settings
Loading...