Answer 1: at this page, you can read:
"It is important to note that the previous definition used the word 'action’. The garbage collector will not run after each microflow, for example a sub-microflow will not initiate the garbage collector. Any action that requires a transaction, such as a click on a microlfow button, a click on the save button, scheduled events, etc. are all actions that can initiate the garbage collector."
Since your microflows are run in the same transaction, nothing happens. The list is not cleared, it still uses memory, because it is still in use.
Answer 2: No, because your transaction is not finished, so all these changes have not been committed to the database, and are still in memory.
What you (probably) should do is implement batching behavior, as shown here. Note: although this is from the 4.0 reference guide, it is still applicable to Mendix 5. Mendix optimizes this batching pattern to reduce the memory required, I believe by doing intermediate commits.
[edit] In response to Stephan:
I created a simple microflow (see here) which updates a string attribute of a list of objects. Then, I clear the list. While debugging, I set the log levels to trace to see what is happening. I see the following in the log:
On the commit action, SQL UPDATE queries are executed. After the end action in the microflow, the following information can be seen in the log:
Attempted to add id [MendixIdentifier:: id=3659174697238529 objectType=MyFirstModule.SomeEntity entityID=13] to client rootset but it was already present.
From this, I conclude that:
(1) SQL call:
SQL: SELECT "myfirstmodule$someentity"."id", "myfirstmodule$someentity"."stringtobeset" FROM "myfirstmodule$someentity" WHERE "myfirstmodule$someentity"."id" IN (3659174697238529, 3659174697238530, 3659174697238531, 3659174697238532, 3659174697238533, 3659174697238534, 3659174697238535, 3659174697238536, 3659174697238537, 3659174697238538, 3659174697238539, 3659174697238540, 3659174697238541, 3659174697238542, 3659174697238543, 3659174697238544, 3659174697238545, 3659174697238546, 3659174697238547, 3659174697238548, 3659174697238549, 3659174697238550, 3659174697238551, 3659174697238552, 3659174697238553, 3659174697238554, 3659174697238555, 3659174697238556, 3659174697238557, 3659174697238558, 3659174697238559, 3659174697238560, 3659174697238561, 3659174697238562, 3659174697238563, 3659174697238564, 3659174697238565, 3659174697238566, 3659174697238567, 3659174697238568, 3659174697238569, 3659174697238570, 3659174697238571, 3659174697238572, 3659174697238573, 3659174697238574, 3659174697238575, 3659174697238576, 3659174697238577, 3659174697238578, 3659174697238579, 3659174697238580, 3659174697238581, 3659174697238582, 3659174697238583, 3659174697238584, 3659174697238585, 3659174697238586, 3659174697238587, 3659174697238588, 3659174697238589, 3659174697238590, 3659174697238591, 3659174697238592, 3659174697238593, 3659174697238594, 3659174697238595, 3659174697238596, 3659174697238597, 3659174697238598, 3659174697238599, 3659174697238600, 3659174697238601, 3659174697238602, 3659174697238603, 3659174697238604, 3659174697238605, 3659174697238606, 3659174697238607, 3659174697238608, 3659174697238609, 3659174697238610, 3659174697238611, 3659174697238612, 3659174697238613, 3659174697238614, 3659174697238615, 3659174697238616, 3659174697238617, 3659174697238618, 3659174697238619, 3659174697238620, 3659174697238621, 3659174697238622, 3659174697238623, 3659174697238624, 3659174697238625, 3659174697238626, 3659174697238627, 3659174697238628)
In response to Rom van Arendonk's answer:
Answer 1) Agree
Answer 2) Disagree
I believe there is a performance gain when you clear lists, since memory used by Mendix != database memory. I wrote on my blog the following:
The clear list action empties the objects from the targeted list, consequently the objects in the list are unavailable further on in the microflow. The load on memory can benefit greatly from the clear list action, specially in large memory consuming microflows. However clearing a list also takes up resources from the server. To understand the dynamics of memory consumption we need to look at two memory management systems on top of each other: “the Mendix Platform internal memory, which stores all non-persistent objects and all changed objects. And the regular Java Garbage collector which cleans up all objects as soon as the Platform is done with them. The built in Mendix garbage collector will not execute until the end of the microflow. That means that when you change an object, those changes will sit somewhere in memory as well. For the Mendix garbage collector it makes no difference since the Mx Garbage Collector will not be executed until the end of the microflow. There is also the Java Garbage Collector. This process runs whenever needed and cleans up all objects that are no longer referenced from memory. If you remove items from the list it will allow the JGC to collect those objects and free memory more…(Mx). Make sure that you commit the changes first, because that will ensure that these objects are added to the database transaction and kept in database memory till they are really stored in the database (end of transaction/microflow is reached).
I refer to the answer provided by Jasper van der Hoek in this topic
@Rom could you please elaborate why you think this wouldn't work?
With kind regards, Stephan