Performance is an important factor in managing your smart desktop and, as with any software, you’ll need to tweak some performance aspects until you’re happy with it. For this reason, most desktop agents promise you some kind of optimization, but not all desktop agents are the same. Finsemble 7.0 introduces process affinity—a new feature to help you manage your smart desktop’s performance. It’s unlike anything available on the market right now, and will ultimately result in a much better user experience for your end users. Let’s examine what we mean we talk about process affinity.
A recent change in Electron
Until recently, Finsemble relied on a feature provided by Electron, called process affinity, to allow it to directly manage the render processes for each web app. This worked well from the perspective of managing app performance, allowing fine control over how processes are grouped together to save on memory usage, or assigned separate processes to ensure unrestricted access to CPU resources. But to improve the security and maintainability of Electron, its maintainers discontinued this feature in version 14. Now, those who depended on Electron’s process affinity for smart desktop management must find a different solution.
Finsemble took the challenge head on and found an approach that allows you more control over process management while maintaining security through alignment with Chromium’s process models—it’s our own proprietary version of process affinity.
Performance and process management on the smart desktop
Performance and process management are important topics for any enterprise software. Web browser render processes tend to be single-threaded (that is, they run on a single CPU, and can only service a single window or app at a time). Each also has its own memory footprint in addition to what they use to render each app. As a result, the more of them you have, the more memory you are using, but also the more of them you have the more freely your web apps can access CPU resources. Because PCs have a lot of memory these days, browsers tend to allocate lots of render threads. Often they allocate more than you have processors, and so they have to manage how much processor time each process gets.
But Finsemble is not a browser. Finsemble manages many more app windows than a typical browser does. That’s because desktops in financial services tend to use more screens and display more apps than in any other industry. A typical user, in a domain other than financial services, opens a lot of tabs per window. The browser can safely deprioritize the tabs and windows that aren’t visible because what’s visible is likely what’s most important to the user. Finsemble can do that too, but it’s not as useful—one of the values of a smart desktop being that all apps are visible at the same time. As a result, we need other ways to manage the allocation of CPU resources.
Second, a smart desktop typically includes additional windows for user interface controls such as toolbar, dialogs, menus, preference panels, not to mention blotters, charts, and the micro-front ends that are rapidly replacing monolithic desktop apps. These windows are often idle unless the user is actively interacting with them. This results in Finsemble managing a large number of windows, many of which are not contending for CPU resources. Each of these windows having its own render thread would be a monumental waste of memory, which in turn would negatively affect performance. To avoid this waste, Finsemble lets some windows share threads, and as a result it saves a lot of memory.
In contrast, apps that react to market events, such as a blotter or pricing chart, are constantly rendering and need access to CPU all the time. These apps are highly likely to block the rendering or comms of other apps, or be blocked by them, if they share a render process. Because these apps are critical to trading workflows, a couple of seconds delay rendering could be a huge deal. For this reason, Finsemble makes sure you can take control of process management so you can ensure these apps never get blocked.
Process affinity is an excellent means of configuring process management for your apps because it allows you to specify which app windows are allowed to combine on the same render thread to save memory. You can also use process affinity to specify which app windows should be assigned to a dedicated thread so that they get unrestricted access to the CPU. Finsemble’s built-in UI and desktop services are already configured to use this system to keep Finsemble’s base memory footprint low and to ensure CPU access for key system services.
Replacing process affinity in Finsemble
The needs of performance and process management must be balanced against security concerns. If a hacker manages to exploit a vulnerability in the browser and escape its process sandbox, they might be able to access data from websites rendered by the same render process. This is why Chromium’s process models enforce a policy called site isolation. This policy ensures that only processes from the same site (a common domain and protocol, ignoring sub-domain and port) can be combined. Of note, Electron’s process affinity feature cut across site isolation, allowing processes from different threads to be combined—which is why it was ultimately removed from Electron to improve security.
Rather than relying on a browser’s usual approach to process management, Finsemble now provides its own implementation of process affinity. Our approach respects site isolation while at the same time giving you fine control over the allocation of processes and memory.
Configuring a process affinity is as simple as tagging an app with a particular affinity, either in Finsemble’s Smart Desktop Designer (SDD) or in your desktop’s config. Finsemble combines apps from the same site into a common render thread. It’s safe because they have the same affinity. You can disable affinity for an app by setting it to false, which will ensure the app configured this way always gets its own render process.
Finsemble follows the security principle of site isolation and only combines processes from the same site. Therefore, you’ll need to customize your affinity settings less often because apps from different sources will always be put into separate processes.
How Finsemble compares to other solutions
As explained above, other desktop agents used to offer process affinity, but no longer can due to Electron’s sunsetting of the solution. Now, all they can do is let you specify one of two options: either all pages of an entire site share a single process, or each tab and each instance has its own process. For example, multiple Google apps, such as Mail, Calendar, and Spreadsheets will either all be in one process, or each will have a separate dedicated process. There are no other options. Other vendors don’t (or can’t) allow you to group processes at all, and instead offer some minor stopgap measures such as lazy loading windows that aren’t visible.
We believe our process affinity will give you and your end users a better experience, and we’re thrilled to be able to offer this in Finsemble 7.0.
For more info, see process management in our documentation.
