aware_support wroteA) I don't have an exact answer for this, obviously. The best I can say is "not much".
This figure (whatever it is) is NOT useful and shouldn't be used in any calculations or estimates - it's not an indication of anything.
EVERYTHING depends on other aspects of your application - i.e. how big your objects are, how many you return by your queries, what you do in your processes and rules etc
B)
- Reports can be memory hungry
- FIND actions that return many big objects are definitely memory hungry
Thanks Vlad;
A while back I did a major optimization in my old app and I learned a lot about what was happening behind the scene. In particular, when a Tenant as LoggedInUser would log in with all the child tables attached to it, the old way, I had many rules to do things with Child and grand children. This would take a major toll on the system or every time I had a field in the LoggedInUser and would change, it would trigger all the rules and create a cascade reaction.
I did a huge change and the app was like night and day different. A process that used to take 90 seconds was changed to 4 seconds.
So I do I agree how we write the app will have a major impact and I learned that in the hard way.
My question was, If someone did a good job to write efficient code, what would be the bare minimum system's memory usage, if everything was done right. But your answer "The best I can say is "not much", is good enough for the BASE requirement.
Regarding Object size, I'm actually contemplating of breaking large objects into one-to-one relationships to avoid carrying a FAT object all the time. So Thank you for confirming that.
In my old app, I removed many actions in the rules and turned them into "On demand" Ad hoc process. User will initiate it to get the answer, rather system doing it automatically all the time.
Last, is to write efficient Scheduled processes that does not block the main system.
