(Update: there is a PDF version of this series of blog posts now available: Performance Comparison from Delphi 2010 to XE6)

Introduction

With the release of Delphi XE6 and Embarcadero’s emphasis on Quality, Performance, and Stability (QPS), I wanted to see for myself the level of improvement, especially in performance. Delphi XE6 is definitely faster and more responsive than the last few versions, especially in FMX, but I wanted to see if I could quantify the performance improvement. There have been a couple recent articles and posts about XE6’s speed (see http://www.dewresearch.com/news/232-rad-studio-xe6-lo-and-behold- and http://www.delphitools.info/2014/05/07/a-look-at-improved-inlining-in-delphi-xe6/). This series of blog posts document my explorations into the performance differences between Delphi 2010, XE, XE2, XE3, X4, XE5, and XE6. Before starting, I made some predictions about what I would see when comparing Delphi 2010-XE6.

EXE size will probably increase with every version of Delphi. This was based on the fact that every version of Delphi has been adding to the runtime library (RTL). After using Borland/CodeGear/Embarcadero products for almost 2 decades, I would be surprised if the linkers have improved much to remove unused code.

This was based on the fact that every version of Delphi has been adding to the runtime library (RTL). After using Borland/CodeGear/Embarcadero products for almost 2 decades, I would be surprised if the linkers have improved much to remove unused code. FMX executables will be larger than VCL executables. This is completely expected as FMX controls are non-native controls (i.e., they don’t use OS level equivalents) so all the drawing and interaction code must be compiled into the executable.

This is completely expected as FMX controls are non-native controls (i.e., they don’t use OS level equivalents) so all the drawing and interaction code must be compiled into the executable. FMX executables will be slower than VCL executables, though each new version of Delphi for a platform should improve. See second bullet above. However, I expect Embarcadero has been working hard on improving FMX execution so I would expect every version to be slightly faster than the previous.

See second bullet above. However, I expect Embarcadero has been working hard on improving FMX execution so I would expect every version to be slightly faster than the previous. Win32 and Win64 compilation should be faster than other platforms. Embarcadero has a long history with developing for the Windows platform so these versions should be far superior to other platforms. Also, with the use of LLVM compiler and linker, I expect the compilation to be MUCH slower as now Object Pascal becomes a at least 2-pass compiler: compilation of object pascal into LLVM bytecode and then the compilation and linking of that code into the final platform executation. As LLVM bytecode from what I understand is language independent, I would expect it does 2 pass compilation like C.

Embarcadero has a long history with developing for the Windows platform so these versions should be far superior to other platforms. Also, with the use of LLVM compiler and linker, I expect the compilation to be MUCH slower as now Object Pascal becomes a 2-pass compiler: compilation of object pascal into LLVM bytecode and then the compilation and linking of that code into the final platform executation. As LLVM bytecode from what I understand is language independent, I would expect it does 2 pass compilation like C. Windows FMX executables will be faster than other platforms’ FMX executables. I have much less confidence in this prediction as the LLVM compilers for each platform are not under Embarcadero’s control so it is possible that a platform vendor will optimize LLVM code much better than Embarcadero. However, I base this prediction on the fact that it is far easier to debug and optimize on Delphi’s native platform than other platforms so I expect that Windows will be where Embarcadero has put in most of their optimization efforts.

Methodology

For the tests in these blog posts, I created sample applications and compiled them in Release configuration for each version of Delphi 2010 to XE6 (if applicable). All compilation tests (including for OSX, iOS, and Android targets) were performed on my Windows 7 box, and, if possible, compiled from the command line to avoid Delphi IDE overhead (this was not possible with some of the mobile tests). Windows testing was performed on this box (Microsoft Windows 7 64-bit, Intel I7 930 @ 2.8 GHz CPU, and 6 GB RAM) with all applications except Microsoft Excel (to record test results) closed. iOS applications were tested on an iPod touch deployed directly to the device in debug mode. Android app were tested on a Nexus 7 (2013) deployed directly to the device in release mode. iOS applications by necessity were in Debug configuration in order to be able to compile and deploy them to my iOS device. Every test was performed a minimum of 3 times. The best 3 times were averaged to produce a final value.

Hello World

My first test was to create a slightly complex Hello World Delphi application for VCL, FMX, and Mobile (iOS and Android). This application is a variant of the classic Delphi application of a TEdit, TListBox, and TButton. Instead of one add of the TEdit constant every click of the button, each click would fill a TListBox or a TMemo with some number of repetitions. The TListBox.Items.BeginUpdate/EndUpdate and TMemo.Lines.BeginUpdate/EndUpdate could be turned on or off. In addition, a number could be optionally be appended to each TEdit string (to avoid any efficiencies with using the same string each addition). The Hello World source code for VCL, FMX, and Mobile can be downloaded here.

Tests

Each week, I will add a new blog post detailing different performance tests.