Hi Chris, Good questions. Here are my thoughts on them based on what I've picked up from the World Tour and Summits.
On Wed, Jun 26, 2019 at 12:31 AM Chris Belanger via 4D_Tech < 4d_tech@lists.4d.com> wrote: > 1) What is the reasonable limit as to how many windows/dialogs should get > opened in the same process? > This is going to be limited by the resources available to 4D. A laptop with the minimum RAM and processor is going to have a lower limit than a nice new Mac Pro by a long way. But there's no reason to be opening a huge number of windows. A window is really a UI portal as it were. We no longer need to hack certain operations with 'offscreen' or 'hidden' windows so a good design should open a window for something useful. On top of that now it's really easy and fast to completely repurpose what a window is 'doing' anyway. You could design a window interface to be a lot like the OS window interfaces are - you display something and then completely change it based on a user action. But now we could revert to any previous window content like the back button on a Finder window. You would have to retain the displayed form and the Form contents but with that info you could reload a past window. So I think this is a case where the technical limit on the number of windows is less important than building a good design for the interface. > 2) do windows that share the same process also share processing time? What > I mean is: If window A is executing, does window B have to wait until > Window A is done before any processing it does would start (think CALL FORM > ( window ) )? > > For example: Window A is doing a QUERY that takes a few seconds. Does that > make Window B (in the same process) unresponsive until Window A has > finished the QUERY? > Prior to preemptive processes each instance of 4D ran on a single core of the machine. How the CPU cycles were allocated and prioritized was between 4D and OS. To us it looked like multiple processes were running 'parallel' but it was all happening on a single core. The only way you could truly have parallel processing was by using server side processes or EXECUTE ON CLIENT and each of those instances were limited in the same way. With a preemptive process you can truly have different processes running concurrently on different cores. Thomas Maul has some great demos of this. If you aren't a Partner (they may be walled off from non-partners) check out a presentation he did for 4DMethod <https://4dmethod.com/>. He also includes a demo of why pre-emptive processing only matters on actual hardware, not virtualized machines. I forget if that's in the 4DMethod preso or I saw it at a Summit. Bottom line: preemptive is meaningless on a virtual machine because the virtual machine is running virtual cores and then entire virtual machine is running on a single instance of the host machine. So, if you plan to deploy on AWS or the like don't worry about preemptive, just use CALL WORKER. So all the windows in the UI process will work, essentially, like the windows in the separate processes we used to use. 4D has optimized things like query a lot, for example. And the speed is improved significantly. I hear in v18 ORDA may be as fast as classic 4D queries. > 3) I used separate processes before because it was possible to do > ‘parallel processing’ that way. Because windows were in separate processes, > anything one window was working on would not impact the responsiveness of > other windows. > Is it still advisable to break out windows under its own process if it may > need to do substantial processing at times? > It would be better to break out the heavy operations using CALL WORKER. This is really what it's designed for. Underlying all this is the question of memory management. I have the impression 4D is committed to optimizing memory use. New process <https://doc.4d.com/4Dv17R5/4D/17-R5/New-process.301-4128085.en.html> recommends 0 for the stack size, "Pass 0 in stack to use a default stack size, suitable for most applications (recommended setting)." The docs go on to say the size is not total process memory and is influenced by things like number of windows, number of forms, and so on. This isn't anything new and doesn't address the situation you start off asking about. I expect the memory allocation when you pass 0 stack size has been addressed but it would be good for someone closer to the engineering team to weight in on it. -- Kirk Brooks San Francisco, CA ======================= What can be said, can be said clearly, and what you can’t say, you should shut up about *Wittgenstein and the Computer * ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
