Hello World Mobile Execution (Speed) Tests
Now that we have finished comparing execution on Win32, Win64, and OSX, we are finally going to compare performance on mobile devices! We created a mobile app version of the Hello World project. It is directly comparable to the desktop version, using TMemo, TListBox, TButtons, and TLabels (see Figure)
For testing iOS apps, we used an iPod Touch with 32GB. For testing Android apps, we used a Nexus 7 (2013) with 32GB.
Because the speed of the mobile devices is so much slower than our desktop machines, we tested adding 10, 100, and 1000 items or lines instead of 100, 1000, and 10000 like the desktop versions. This was only necessary when the BeginUpdate and EndUpdate methods were not called.
Please notice that the FMX charts have a logarithmic y-axis for execution time. With FMX, execution times vary so greatly between a small number of items and a large number of items that filling a TListBox or a TMemo with 1000 items would swamp out the other results and make them appear tiny and indistinguishable.
Hello World, Mobile FMX, iOS
Our first tests are with filling the TListBox on an iOS device. Since Delphi XE4, Delphi has supported deploying to iOS devices. Note that the Delphi XE4 app was compiled with debug. Delphi XE5 and XE6 can deploy release versions directly to the device without requiring certificates. However, this was not true with Delphi XE4 but as we will see, it doesn’t seem to have slowed the app down.
Delphi XE6 does well when filling a TListBox on an iOS device. For 10 items, it manages to be over 2x faster (416 ms) than the slowest version, Delphi XE4, when BeginUpdate/EndUpdate are not called. At 100 items, it is still 1.5x faster (11.9 secs) than XE4. Only at 1000 items is it slowest, however, “slowest” is relative here as Delphi XE5 which is fastest still took over 16 minutes. When BeginUpdate/EndUpdate are used while filling a TListBox, Delphi XE5 is the fastest. Delphi XE6 is last in this case, but the differences are minor as it fills a TListBox with 100 items in 189 ms compared to XE5’s 102.3, with 1000 items in 3.1 secs compared to XE5’s 2.2 seconds, and with 10000 all of the Delphi’s are slow, taking 2.8 minutes for XE5 and 3.19 minutes for XE6.
It must be mentioned that Delphi XE4 did well filling a TListBox when the BeginUpdate and EndUpdate methods are called, nearly equaling XE5. This is important as Delphi XE4 completely dominates when filling a TMemo, with or without calls to BeginUpdate/EndUpdate. Delphi XE6 is in second managing to beat XE5 in every case except when filling a TMemo with 10 lines (51 ms vs 33 ms).
Hello World, Mobile FMX, Android
Our last platform is Android. Note that only Delphi XE5 and XE6 can target this platform.
No clear winner emerges for the Android platform, though Delphi XE6 is the all-around better Delphi for Android. If you look at the filling TListBox chart, Delphi XE6 is faster at filling a TListBox with less than 1000 items and no BeginUpdate/EndUpdate. However, when the BeginUpdate and EndUpdate methods are called, Delphi XE5 is faster (157 ms at 100 items, 941 ms at 1000 items, and 41 seconds at 10000 items.
When filling a TMemo, Delphi XE5 and Delphi XE6 are essentially tied except for one important caveat. Delphi XE5 is almost twice as fast as XE6 at adding 10 lines (and no BeginUpdate/EndUpdate); however, that does not mean much as it is only a difference of 22 ms. The glaring discrepancy is that Delphi XE6 is over 7x faster than XE5 in filling a TMemo with 1000 lines (and no BeginUpdate/EndUpdate). It takes 20 seconds for XE6; over 2 minutes later XE5 finishes.
Stay tuned for more next week… 🙂
That’s it for the Hello World project execution speed results. The Hello World project is a simple application/app that provided some interesting comparisons between the different Delphi versions on various platforms. It showed the work that needs to be done to improve the FMX versions. However, the Hello World project is limited and truly only tested a couple “standard” controls (TListBox and TMemo).
Next week, we are going to show speed results from sample applications using the Inference Engine Component Suite (IECS). The IECS is a large component library (96K lines of engine code and another 48K LOC for dialogs) for developing expert systems with Delphi. It uses lots of interfaces, generics, parsing/string manipulation, and 100s of classes. It works from Delphi 2010 through XE6 and for all platforms that Delphi supports. It should provide very interesting non-visual execution results.
We are going to follow that up with tests using the RiverSoftAVG SVG Component Library (RSCL). The RSCL will only test Delphi XE2 through XE6. However, it renders SVG files using low-level canvas operations (gradients, paths, text, etc) and is available for VCL and FMX. It uses GDI+ for VCL (which is a software renderer with comparable features to the FMX TCanvas) so it should provide a good test of the FMX DirectX and OpenGL hardware-based rendering. The RSCL is also able to build SVGs using the FMX shape primitives (TRectangle, TPath, TText, etc); it should reveal any optimizations (or lack thereof) Embarcadero has been doing with the low-level primitives from which most FMX controls are built.
That’s it for this week. I hope you are enjoying this series of blog posts. Happy CodeSmithing!