Hybrid app implementations have enhanced the ability of web developers to deliver desktop apps, but the decreased performance and increased memory consumption are a significant downside. Since desktop apps run the application code locally on your machine, we cannot compromise on performance and memory usage by getting rid of native code. The future of desktop apps still lies in native code.
In this blog post, we’ll look at why native code is the future of desktop apps by comparing the performance and memory usage of Native Windows Development tools with other desktop application development frameworks such as WPF .NET and Electron.
Table of Contents
Can Electron deliver an optimized solution?
Visual Studio Code is an Electron app and generally performs pretty well. A developer might think that all Electron apps can achieve the same performance as Visual Studio Code but generally that is probably not the case. Microsoft has a huge task force of developers working on the project and has put a lot of effort, time, and money to optimize the VS Code application. In most cases, other companies do not have the enormous budget as giants like Microsoft and hence cannot match the optimization efforts to deliver a high-performant application using Electron.
Running a a few unoptimized applications might still be fine, but we know for a fact that our systems indeed have the capacity to run more. When you choose to operate with more than a few, say five to ten, unoptimized applications then they adversely effect the system and application runtime performance.
In such scenarios, RAD Studio that consists of Delphi and C++ Builder becomes an ideal choice of adoption for desktop application development.
Now let’s look at the performance test results from the Embarcadero Whitepaper.
According to Discovering the Best Developer Framework through Benchmarking by Embarcadero Technologies, the end-product performance, which depends on startup times and runtime memory, is one of the four aspects of effectiveness for the success of applications. The consumers judge applications based on the runtime performance and businesses choose the frameworks that have a higher performance.
The specialists at Embarcadero Technologies used the development and analysis of a benchmark Windows calculator app and evaluated its performance against the Delphi, WPF, and Electron frameworks and libraries.
How does Delphi Contribute to Application Performance and Startup Time?
When it comes to performance and startup time of applications, according to Embarcadero’s commissioned whitepaper, frameworks that produce applications with shorter startup times facilitate good user experiences and minimize the system resources well before the application is ready to be used. Startup time is especially important when loading an executable or application over a network because network speeds can be slower than loading applications via the local hard drive.
According to the experimentation done in the whitepaper, the benchmark calculator app built with Delphi gave a startup time of 0.239 seconds on average from the local files, whereas from the network files, the average time was recorded to be 0.439 seconds. The slowest startup times came out to be 0.687 and 2.416 seconds for local and network files respectively.
In both the cases of WPF and Electron, the benchmark calculator application seemed to have higher startup times as compared to Delphi, making Delphi an ideal choice for adoption.
How does Delphi’s Standing Memory Usage Compare to Others?
Memory consumption when the user of your application is idle and not performing any in-app operations is a matter of utmost consideration. The frameworks that are responsible for producing applications with lower idle time overhead are better and conserve the total system resources. The more memory each individual application on a desktop machine is using, the fewer applications can be opened on the machine at the same time.
According to the experimentation done in the whitepaper, the calculator app built with Delphi averaged 21.1 MB of standing memory usage, whereas the WPF (.NET) framework averaged out to consume 37.3 MB of memory when in an idle state.
Why does Delphi Make the Best Fit to Handle Peak Memory Usages?
The performance and memory utilization of the application from startup time to its peak usage is one of the decisive factors in choosing a particular technology over others. Good frameworks that allow the execution of native code apply personalized memory release techniques that result in boosting up the entire system performance.