Monthly Archives: June 2014

Of Paranoia and Enumerated Types

They say that just because you are paranoid, it doesn’t mean that someone is not out to get you. ¬†I have never been paranoid, but I think I might start, as I think someone at Embarcadero¬†is out to get me… or at least, out to get third party developers who create components for FMX ūüôā ¬†Supporting FMX components is simple masochistic fun,¬†especially when you try to develop cross-library components (i.e., support VCL and FMX). ¬†When I get especially frustrated,¬†I start imagining that there is¬†someone at Embarcadero, laughing maniacally every time a new release of Delphi and FMX come out. ¬†It is hard to annoy¬†your developer community as well as Embarcadero has unless you are truly trying. ūüôā

Each version, Embarcadero likes to mix things up as they work¬†to make FMX¬†better, giving FMX component developers a perpetual¬†thrill ride. ¬†Not only do FMX component developers have to deal with bugs and slow performance, we have the joy of managing the constantly¬†changing hierarchy, modified method names, and changed method signatures. Sometimes, seemingly just for giggles, types and classes will move to new units, giving FMX developers a fun whack-a-mole, find-that-class game with each release. ¬†Supporting multiple versions of FMX from one code base is an IFDEF heaven. ūüôā

All of which leads up to the point of this rant, I mean post, and one of my new pet peeves.  Enumerated types (and sets) are one of my favorite features of the Pascal language.  They are a joy to use: elegant and descriptive, beautifully type-safe while providing amazing power, especially with sets.  They are one of the features I miss the most when I have to go use another language.  However, it seems like Embarcadero is trying to ruin them for me, at least in FMX.

In FMX, every enumerated type is compiled with the SCOPEDENUMS directive on. ¬†For those who don’t know, when an enumerated type is compiled with SCOPEDENUMS on, you have to type the enumerated type when you use it, e.g., ¬†this is not¬†valid

MyControl.Align := alClient;

Instead, you are required to type:

MyControl.Align := TAlignLayout.alClient;

In my opinion, SCOPEDENUMS are one of the stupidest ideas that Embarcadero has ever adopted. ¬†I know, I know, other languages have the same thing. ¬†Well guess what, I like¬†that you didn’t have to do that in Pascal. ¬†What is the point of having a strongly-typed language if you have to do all the work for the compiler anyway?

For someone who tries to create code that works in both FMX and VCL, the SCOPEDENUMS directive is especially trying.  Either you have to type:

MyControl.Align := {$IFDEF FMX}TAlignLayout.{$ENDIF}alClient;

or

{$IFDEF FMX}
  TMyAlign = TAlignLayout;
{$ELSE}
  TMyAlign = TAlign;
{$ENDIF}
MyControl.Align := TMyAlign.alClient;

Digression: Note that the {$DEFINE FMX} is something I define to say if I am compiling for FMX or VCL., similar to what is discussed here.  In practice, I have one unit called FMX.RS.Something.pas that is defines the FMX and then includes the common unit, e.g.,

unit FMX.RS.Charts;
{$DEFINE FMX}
{$INCLUDE RSCharts.pas}

I found this solution on the forums one day, found the idea elegant, and use it extensively to make all RiverSoftAVG.com cross-library components.

But back to my rant…¬†Embarcadero’s practice of using SCOPEDENUMS for FMX caused a lot of unnecessary code in my libraries. ¬†I found the decision dumb, but I did the work, I could get around it, and life was¬†good again…

…Until Delphi XE6. ¬†In Delphi XE6, someone at Embarcedero decided to up the dumb level to 11. ¬†ūüôĀ ¬†In Delphi XE6, FMX enumerated types do¬†not include the prefix! ¬†TAlignLayout is no longer:

TAlignLayout = (alNone, alTop, alLeft, alRight, alBottom, alMostTop, alMostBottom, alMostLeft, alMostRight, alClient,alContents, alCenter, alVertCenter, alHorzCenter, alHorizontal, alVertical, alScale, alFit, alFitLeft, alFitRight);

but this:

 TAlignLayout = (None, Top, Left, Right, Bottom, MostTop, MostBottom, MostLeft, MostRight, Client, Contents, Center, VertCenter, HorzCenter, Horizontal, Vertical, Scale, Fit, FitLeft, FitRight);

 TAlignLayoutHelper = record helper for TAlignLayout
 const
 alNone = TAlignLayout.None deprecated 'Use TAlignLayout.None';
 alTop = TAlignLayout.Top deprecated 'Use TAlignLayout.Top';
 alLeft = TAlignLayout.Left deprecated 'Use TAlignLayout.Left';
 alRight = TAlignLayout.Right deprecated 'Use TAlignLayout.Right';
 alBottom = TAlignLayout.Bottom deprecated 'Use TAlignLayout.Bottom';
 alMostTop = TAlignLayout.MostTop deprecated 'Use TAlignLayout.MostTop';
 alMostBottom = TAlignLayout.MostBottom deprecated 'Use TAlignLayout.MostBottom';
 alMostLeft = TAlignLayout.MostLeft deprecated 'Use TAlignLayout.MostLeft';
 alMostRight = TAlignLayout.MostRight deprecated 'Use TAlignLayout.MostRight';
 alClient = TAlignLayout.Client deprecated 'Use TAlignLayout.Client';
 alContents = TAlignLayout.Contents deprecated 'Use TAlignLayout.Contents';
 alCenter = TAlignLayout.Center deprecated 'Use TAlignLayout.Center';
 alVertCenter = TAlignLayout.VertCenter deprecated 'Use TAlignLayout.VertCenter';
 alHorzCenter = TAlignLayout.HorzCenter deprecated 'Use TAlignLayout.HorzCenter';
 alHorizontal = TAlignLayout.Horizontal deprecated 'Use TAlignLayout.Horizontal';
 alVertical = TAlignLayout.Vertical deprecated 'Use TAlignLayout.Vertical';
 alScale = TAlignLayout.Scale deprecated 'Use TAlignLayout.Scale';
 alFit = TAlignLayout.Fit deprecated 'Use TAlignLayout.Fit';
 alFitLeft = TAlignLayout.FitLeft deprecated 'Use TAlignLayout.FitLeft';
 alFitRight = TAlignLayout.FitRight deprecated 'Use TAlignLayout.FitRight';
 end;

What’s the big deal you say? ¬†After all, they provide backwards compatibility for using alClient, etc? ¬†Ignoring that they just added a bunch of extra code for no reason (possibly bloating EXE sizes) and just wasted a¬†record helper in order to provide backward compatibility for something they just broke, the big deal to me is that if you use TAlignLayout.alClient, you get the stupid deprecated warning, and warnings and hints are kind of a no-no when you are trying to develop quality components (for some reason, people get anxious ūüôā ). ¬†A possibly¬†even BIGGER DEAL (your mileage may vary)¬†is that they broke compatibility with streaming in earlier versions of Delphi! ¬†Once a form is saved in Delphi XE6, any alClient, alLeft,¬†alRight, etc¬†are converted to Client, Left, Right, etc making the form unusable in earlier versions of Delphi. ¬†Aarrgh! ¬†There are some truly choice words I said when I realized I completely broke a dialog in the IECS by saving it in Delphi XE6 (thankfully, I keep weekly backups).

Anyway, glad to get that off my chest. ¬†Now, I am not truly paranoid, and I know that Embarcadero is not truly out to get me. ¬†Eventually, my hope is that they will get FMX mature enough that you don’t see such core, breaking changes occurring each Delphi version. ¬†I know in the grand scheme of things, I would rather have a stable, fast, working FMX than for them to worry about little ol’ developers like me. ¬†However, if I ever walk past one of Embarcadero’s¬†offices and hear an evil chuckle from within, I am not going to be held responsible for my actions. ¬†ūüôā

Thank you for reading my rant.  Comments, as always, are welcome.

Happy CodeSmithing!

Performance Comparison from Delphi 2010 to XE6 PDF

The Performance Comparison from Delphi 2010 to XE6 series of blog posts has easily been the most popular ones I have ever done.  However, I know that it can be difficult to read as the blogging format is not really the best format for what is essentially an article.  I received a couple requests for a PDF version of the blog posts.  If you want to read the series as one big PDF (59 pages), you can download it here: Performance Comparison from Delphi 2010 to XE6.  It has been lightly edited from the blog to enhance the clarity and continuity.

Enjoy!  Happy CodeSmithing!

Performance Comparison from Delphi 2010 to Delphi XE6 (Conclusion)

The Last Chapter

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. Before starting, I made¬†some predictions¬†about what I would see when comparing Delphi 2010-XE6. ¬†Let’s see how I did:

  • EXE size will probably¬†increase with every version of Delphi. ¬†This turned out to be mostly true. ¬†Each version of Delphi has increased¬†the EXE size over the one before… EXCEPT¬†this ignores the one proverbial elephant in the room, Delphi XE3. ¬†Delphi XE3 massively increased EXE sizes, both in VCL and FMX. ¬†Thankfully, Delphi XE4 reduced¬†XE3’s excessive weight gain. ¬†However, EXE size has been growing back to XE3 levels with every version since then. ¬†It should be noted that VCL EXE sizes have been growing slower than FMX EXE sizes.
  • FMX executables will be larger than VCL executables.¬†¬†This was¬†definitely true. ¬†This was¬†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.¬† This was mostly true. ¬†Except for where the VCL version is using a software renderer for heavy graphics drawing vs the FMX hardware renderer, the FMX versions are slower than their VCL counterparts. ¬†There was one outlier, when strings are added to a TMemo and BeginUpdate/EndUpdate have not been called, the Delphi XE6 FMX version was faster than the VCL feature. ¬†However, the discrepancy is easily explained¬†as the VCL TMemo draws every string¬†as it is added while the FMX TMemo does not. ¬†The part that is not completely true is that each new version of Delphi would be improving the FMX speed. ¬†Speeds were all over the place, and earlier versions were sometimes significantly faster. ¬†Delphi XE6 is definitely faster than XE5 though.
  • Win32 and Win64 compilation should be faster than other platforms.¬†¬†This was¬†true as well. ¬†The Win32 and Win64 compilers (written by Embarcadero) are fastest. ¬†However, the OSX version (also¬†written by Embarcadero) is very close. ¬†The iOS and Android versions are much slower, even when not counting the deployment step.
  • Windows FMX executables will be faster than other platforms‚Äô FMX executables.¬†¬†This was mostly true to true. ¬†Since the test machines were not comparable, it was difficult to really test this. ¬†However, when drawing the RSCL directly to the canvas,¬†the OSX implementation was comparable¬†to the Win32 implementation. ¬†With the exception of the Clock, the OSX versions cleaned the Win32 versions clocks, being anywhere from 1.2x-4.2x faster.¬†¬†It must be noted that the Windows box (Windows 7 64-bit¬†Intel I7 930 @ 2.8 GHz CPU, ATI HD 5700 graphics card, and 6 GB RAM) and the Mac Mini (OSX 64-bit Intel¬†I7 @¬†2.3 GHz, integrated graphics, and 4GB RAM) are not exactly comparable. ¬†Admittedly, the ATI HD 5700 is almost 5 years old now, but the Mac Mini uses integrated graphics. ¬†Examining the outputs closely, there are slight differences in the output (see the dark lines in the Car). ¬†Generally, however, the output from the OSX versions are excellent. ¬†This hypothesis would need to be more rigorously investigated.

Comparing the competitors…

To make my final evaluation, I wanted to be as objective as possible and use concrete¬†numbers. ¬†I decided to ignore EXE size (Delphi 2010 wins! :-)) and compilation speed (more mixed but generally earlier versions of Delphi). ¬†I concentrated solely on performance metrics. ¬†This means I ignored features (Delphi XE6 wins!), number of platforms (Delphi XE6 wins), and stability (???? wins!) For each test application, I averaged the scores (e.g., the Hello World Listbox performance score is an average of the TListBox scores). ¬†This does mean that the winner of an exponential test (e.g., 1000s of items in a TListBox) can win even if their performance with less items was not the¬†best. ¬†I then normalized the averages (e.g., the winner is equal to 1 and every other version is between 0 and 1 depending on their average). ¬†Finally,¬†I added each test score together to get a maximum score per platform. ¬†For example, the VCL 32-bit score includes the normalized performance scores from the Hello World project (ListBox and Memo), the IECS Advanced Console and the IECS Basic Console (Max of 4 points). ¬†The OSX score includes the¬†normalized performance scores from the Hello World project (ListBox and Memo), the IECS Advanced Console, the IECS Basic Console, RSCL Drawing project, and the RSCL Primitives project (Max of 6 points). ¬†In the graphs below, you can easily see how the normalized scores contributed to each Delphi version’s score. Note that my scores are just for the tests in this series of blog posts. ¬†Other tests would give vastly different results. ¬†This blog post is not meant to be a recommendation of one Delphi version over another.

Now for the awards ceremony…

Overall Performance Score Comparison, Win32 VCL

Overall Performance Score Comparison, Win32 VCL

Surprisingly, Delphi XE6 wins the gold award in my performance tests for Win32 VCL.¬† The differences are extremely minor between all versions of Delphi so this coveted¬†award could have gone to any of them ūüôā ¬†Delphi XE3 manages second place and a silver medal. ¬†Delphi XE scores the third place bronze award.

Overall Performance Score Comparison, Win64 VCL

Overall Performance Score Comparison, Win64 VCL

For Win64 VCL (dropping Delphi 2010 and XE from the running), Delphi XE2 manages to barely eke out the gold award.  Delphi XE6 wins silver and XE5 bronze.

Overall Performance Score Comparison, Win32 VCL

Overall Performance Score Comparison, Win32 FMX

Moving to FMX, the performance differences get much larger.  Delphi XE3, despite its huge EXE sizes and poor Memo performance, produces the fastest FMX executables on Windows in these tests to win a gold medal.  Its ListBox performance is what really stands out.  Delphi XE4 makes a very strong second place showing for silver.  Bronze goes to Delphi XE6.

Overall Performance Score Comparison, Win64 FMX

Overall Performance Score Comparison, Win64 FMX

Going to 64-bit, Delphi XE3 again wins the gold with Delphi XE4 getting the silver.  Delphi XE6 comes again in third place, though its score improved noticeably over 32-bit.

Overall Performance Score Comparison, OSX

Overall Performance Score Comparison, OSX

Switching to the Mac, Delphi XE4 wins its first gold medal.  Delphi XE6 sneaks past XE3 to win the silver.

Overall Performance Score Comparison, iOS

Overall Performance Score Comparison, iOS

Shifting to mobile, we are down to Delphi XE4, XE5, and XE6.  Delphi XE4 wins another gold medal for the iOS platform on its solid memo performance.  Delphi XE6 gets second place for the silver and XE5 trails for the bronze.

Overall Performance Score Comparison, Android

Overall Performance Score Comparison, Android

For our last platform, Android, Delphi XE6 wins handily, easily beating XE5.

Conclusion

So what does this mean? ¬†How did Delphi XE6 perform on its mantra of “Quality, Performance, and Stability?” ¬†As far as this series of performance blog posts are concerned, Delphi XE6 did neither as well as I hoped nor as bad as I feared. ¬†It only outright won a platform twice (and one of those was by a whisker on Win32 VCL). ¬†However, Delphi XE6 was a solid performer and competitive for all platforms. ¬†Compared to its immediate successor (Delphi XE5), it is a huge advance in performance and nearly brings it back up to the levels of Delphi XE3 and XE4, both of which performed surprisingly well in FMX.

Overall Performance "Medal" Count (Gold=3, Silver=2, Bronze=1)

Overall Performance “Medal” Count (Gold=3, Silver=2, Bronze=1)

If you do a medal count of the different platforms and give 3 points for Gold, 2 points for Silver, and 1 point for Bronze, Delphi XE6 racks up the most points.  Even if you ignore the Android platform, Delphi XE6 still did 1 point better than XE4.  If you then also ignored the iOS platform, Delphi XE6 would still tie with XE3 at 9 points.  Considering that it adds both iOS and Android platforms, seems to have fewer issues compared to Delphi XE3 and XE4, and vastly superior performance compared to Delphi XE5, I would say that Embarcadero achieved their goal. Almost a month and over 12,000 words later, I have finally finished this series of blog posts on the performance comparison from Delphi 2010 to Delphi XE6.  I hope you have enjoyed them.  It was a ton of work, but I think it was worth it.  Happy CodeSmithing!

Performance Comparison from Delphi 2010 to Delphi XE6 (Part 7b – RSCL Primitives)

RSCL Primitives Application, FMX, Win32

In our last blog post, we compared SVG drawing performance for the different versions of Delphi using low-level canvas routines.  However, the RiverSoftAVG SVG Component Library (RSCL) also contains a TRSSVGPanel component, which is able to generate FMX shape controls (TLayout and TPath mostly) descendants from an SVG to allow GUI interaction.  It was our thought that this could be useful for performance testing FMX primitives speed as these primitives are what controls are made of in the FMX library.  The RSCL converts the SVG elements listed in the last post into the following primitives:

Listing of SVG Primitives created for each SVG

Listing of SVG Primitives created for each SVG

Note that the loading, parsing, and building of the RSCL SVG elements and primitives are not tested in these tables.  Rather, the speed that the FMX library performs in refreshing the display of all the primitives that make up the SVG representation.

Comparison of averaged execution speed for the FMX RSCL Primitives application (Win32) with the baseline GDI+ VCL application, for Delphi XE2 to XE6

Comparison of averaged execution speed for the FMX RSCL Primitives application (Win32) with the baseline GDI+ VCL application, for Delphi XE2 to XE6

Before starting, we again did a sanity test to compare the FMX version to the VCL version. The VCL version uses GDI+, which is a software graphics library, so the hardware-optimized FMX TCanvas operations should be significantly faster.  Thankfully, that is what we see.  Every Delphi version of the FMX application was 4x-5x faster on average than the VCL application (XE6).

Comparison of execution speed for the FMX RSCL Primitives application (Win32) with Delphi XE2 to XE6

Comparison of execution speed for the FMX RSCL Primitives application (Win32) with Delphi XE2 to XE6

Zooming in on the primitives drawing performance for each individual SVG, Delphi XE2 dominates, drawing 2 SVGs fastest outright, tieing in drawing the Clock, and only 2/3 ms behind the leader drawing the Car SVG.  Delphi XE3 does especially poorly in performance.  Delphi XE6 comes in 4th place trailing XE2 by approximately 14%.

Ratio of Drawing vs FMX Primitives execution speed for RSCL applications in Delphi XE2 to XE6 (Win32)

Ratio of Drawing vs FMX Primitives execution speed for RSCL applications in Delphi XE2 to XE6 (Win32)

Comparing performance when drawing directly to the canvas versus using primitives, we see a mix of results.  The Clock and the Car are faster when using primitives, and the Watch and the Flag are faster when using the canvas directly.  Without more extensive profiling, it is difficult to say exactly why this is so.  If you remember the SVG element breakdown from the last post, the Clock and the Car have significantly more gradients and gradients stops and a lot fewer paths than the Watch and the Flag.  Since the RSCL caches Brushes and Pens after the first drawing call, the RSCL primitives do not have an advantage from the greater number of gradients.  It is probable that the FMX library bogs down as the number of primitives goes up.

*Note that Delphi XE3 had visual artifacts drawing the Car and the Watch.  

RSCL Primitives Application, FMX, Win64

Moving to 64-bits, Delphi XE2 again wins and is the only version to actually improve its average score from 32-bits.  It renders the Watch and Flag fastest, ties for the Clock, and trails the leader by 1.66 ms for the Car.  Delphi XE3 continues its poor performance.  Delphi XE6 is approximately 16% slower than Delphi XE2.

Comparison of execution speed for the FMX RSCL Primitives application (Win64) with Delphi XE2 to XE6

Comparison of execution speed for the FMX RSCL Primitives application (Win64) with Delphi XE2 to XE6

Ratio of Win64 to Win32 execution speed for RSCL Primitives applications in Delphi XE2 to XE6 (FMX)

Ratio of Win64 to Win32 execution speed for RSCL Primitives applications in Delphi XE2 to XE6 (FMX)

*Note that Delphi XE3 had visual artifacts drawing the Car and the Watch. 

RSCL Primitives Application, FMX, OSX

When we start testing using the OSX platform, the performance of all versions of Delphi suffer dramatically. ¬†Unlike drawing directly to the canvas, the FMX primitives on OSX are very slow… for Delphi XE3, it is even slower than the non-hardware accelerated GDI+ version!

Comparison of execution speed for the FMX RSCL Primitives application (OSX) with Delphi XE2 to XE6

Comparison of execution speed for the FMX RSCL Primitives application (OSX) with Delphi XE2 to XE6

Ratio of Win32 to OSX execution speed for RSCL Primitives applications in Delphi XE2 to XE6 (FMX)

Ratio of Win32 to OSX execution speed for RSCL Primitives applications in Delphi XE2 to XE6 (FMX)

 

Delphi XE2, XE3, and XE4 suffer the most coming to the OSX platform.  Delphi XE5 and XE6 make great showings in comparison.  Delphi XE5 is the fastest when using primitives by a large margin.  Delphi XE6 is in second place but about 18% slower than XE5.

*Note that Delphi XE3 had visual artifacts drawing the Car and the Watch. 

RSCL Primitives Application, FMX, iOS

Comparing Delphi XE4 through XE6 on mobile, Delphi XE5 maintains its performance advantage.  On iOS, Delphi XE5 is fastest using FMX primitives, with a 6%-7% speed advantage.  The Delphi XE6 numbers are very respectable.  With SVGs with more paths (Watch and Flag), Delphi XE6 manages to be faster than XE4.

Comparison of execution speed for the FMX RSCL Primitives application (iOS) with Delphi XE4 to XE6

Comparison of execution speed for the FMX RSCL Primitives application (iOS) with Delphi XE4 to XE6

*Delphi XE4 was last on iOS.  In addtion, there were minor visual artifacts (gradients) drawing the SVGs.

RSCL Primitives Application, FMX, Android

Our final test in this series of blog posts is on the Android platform.  Delphi XE5 wins the performance crown when using FMX primitives on Android, though it is a narrow victory.  Delphi XE6 loses by over 6% when drawing the Clock.  However, as the number of primitives go up, Delphi XE6 starts catching up and is less than 2% slower when drawing the most complex SVG (Watch).

Comparison of execution speed for the FMX RSCL Primitives application (Android) between Delphi XE5 and XE6

Comparison of execution speed for the FMX RSCL Primitives application (Android) between Delphi XE5 and XE6

Finally!  We are finished with our performance tests!  In the concluding blog post, I summarize the results and discuss how Delphi XE6 did.

Performance Comparison from Delphi 2010 to Delphi XE6 (Part 7 – RSCL)

RSCL Execution (Speed) Tests

Display of the SVG clock using FMX TCanvas operations in the iOS test app

Display of the SVG clock using FMX TCanvas operations in the iOS test app

Last week, we tested the various Delphi versions with sample applications using the Inference Engine Component Suite (IECS).  It provided interesting details for non-visual performance as well as a mix of non-visual and visual performance.  Our final tests are going to use the RiverSoftAVG SVG Component Library (RSCL) to test the graphics performance of the FMX Delphi versions, e.g., Delphi XE2 through XE6.  The FMX TCanvas is graphics hardware accelerated, using DirectX on Windows and OpenGL on OSX, iOS, and Android.  In addition, Delphi XE6 added DirectX 11 support so it will be interesting to see if that makes a difference.

Display of the SVG watch using FMX TCanvas operations in the iOS test app

Display of the SVG watch using FMX TCanvas operations in the iOS test app

About the RSCL Test Applications

There are actually two types of RSCL applications we are going to test.  The first type of RSCL applications will test the drawing speed of the FMX TCanvas routines by drawing SVGs.  They render SVG files using low-level canvas operations (gradients, paths, text, etc) and are available for VCL and FMX.  The VCL versions use GDI+ (which is a software renderer with comparable features to the FMX TCanvas) so they should provide a good baseline of the FMX DirectX and OpenGL hardware-based rendering.

Display of the SVG car using FMX TCanvas operations in the iOS test app

Display of the SVG car using FMX TCanvas operations in the iOS test app

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.

Display of the SVG flag using FMX shape primitives in the iOS test app

Display of the SVG flag using FMX shape primitives in the iOS test app

For simplicity with deploying mobile apps, all of the projects store the test SVGs inside a TClientDataSet in the app/application. The SVG applications are only testing drawing using low-level canvas operations or shape primitives; the loading, parsing, and building of the RSCL SVG elements and primitives are not tested.  There are four SVGs used in the tests:

  1. Clock
  2. Car
  3. Watch
  4. Flag

The following table breaks down the SVG elements that make up each SVG:

Listing of SVG Elements for each SVG

Listing of SVG Elements for each test SVG

Something to note is that these test applications should not be taken as an indicator of the pure TCanvas speed you can get in FMX.  The SVGs are incredibly complicated, with lots of paths, gradients, transparencies, CSS styles, etc.  The RSCL is saving canvas state before drawing each element and restoring canvas state after drawing each element.  Each SVG element has its own brush and pen (or Fill and Stroke in FMX terminology).  There are a lot of canvas operations occurring besides the pure filling of a graphics primitive (rectangle, ellipse, path, etc).

Another thing to note is that these drawing tests are not representative of the RSCL TRSSVGImage component performance.  The TRSSVGImage component draws an SVG once to a backscreen bitmap and then just draws the backscreen bitmap as needed when painting is called for.  These drawing tests deliberately use a TPaintBox and draws an SVG each time the TPaintBox is refreshed.  Even then, we removed the first drawing call from the performance times as the RSCL has to build the Brushes and Pens (Fills and Strokes) in the first drawing call but caches them for later drawing calls.

RSCL Drawing Application, FMX, Win32

Our first series of tests with the RiverSoftAVG SVG Component Library (RSCL) will be the RSCL Drawing application for Win32.  As mentioned earlier in the series, our test machine for Windows is a Windows 7 64-bit Intel I7 930 @ 2.8 GHz CPU, and 6 GB RAM.  The graphics card is an ATI HD5700 (not a top performer) using the latest AMD 14.1 drivers and with DirectX 11.  Note that no special effort was made to choose the TCanvas implementation; we let each Delphi version pick its default.

Comparison of averaged execution speed for the FMX RSCL Drawing application (Win32) with the baseline GDI+ VCL application, for Delphi XE2 to XE6

Comparison of averaged execution speed for the FMX RSCL Drawing application (Win32) with the baseline GDI+ VCL application, for Delphi XE2 to XE6

As a sanity test, we will first compare the FMX version to the VCL version.  Since the VCL version uses GDI+, which is a software graphics library, the hardware-optimized FMX TCanvas operations should be significantly faster.  Thankfully, that is what we see.  Every Delphi version of the FMX application was almost 4x faster on average than the VCL application (XE6).

Comparison of execution speed for the FMX RSCL Drawing application (Win32) with Delphi XE2 to XE6

Comparison of execution speed for the FMX RSCL Drawing application (Win32) with Delphi XE2 to XE6

Zooming in on the drawing performance for each individual SVG, we see that Delphi XE5 drew the Flag fastest, but that Delphi XE4 drew the Watch and Car the fastest.  Every version of Delphi drew the Clock in 7-8 ms (11x-12x faster than the GDI+ performance).  Overall, Delphi XE4 was the fastest in Win32.

*Note that Delphi XE3 had visual artifacts drawing the Car and the Watch.  

RSCL Drawing Application, FMX, Win64

Moving to 64-bit, every version of Delphi was faster than its 32-bit counterpart (running on Windows 7 64-bit).  This time, Delphi XE2 drew the Flag fastest.  Delphi XE6 drew the Watch fastest.  Delphi XE4 was fastest drawing the Car.  We have a 5-way tie for drawing the Clock at 7 ms.  Averaging the results, Delphi XE4 is again the winner for Win64.

Comparison of execution speed for the FMX RSCL Drawing application (Win64) with Delphi XE2 to XE6

Comparison of execution speed for the FMX RSCL Drawing application (Win64) with Delphi XE2 to XE6

Ratio of Win64 to Win32 execution speed for RSCL Drawing apps in Delphi XE2 to XE6 (FMX)

Ratio of Win64 to Win32 execution speed for RSCL Drawing apps in Delphi XE2 to XE6 (FMX)

Comparing the ratio of performance of Win64/Win32, Delphi XE2 and XE6 saw the largest performance gain when moving to Win64.  It is difficult to see if Delphi XE6 gained anything with its DirectX 11 compatibility.

*Note that Delphi XE3 had visual artificacts drawing the Car and the Watch.  

RSCL Drawing Application, FMX, OSX

Things get much more interesting when we move to Mac OSX. ¬†The FMX programs are using OpenGL instead of DirectX. ¬†Delphi XE2 is fastest drawing the Car and ties with XE3 for drawing the Clock. ¬†Delphi XE5 is fastest drawing the Watch; XE3 gets another tie when drawing the Flag.¬†¬†Delphi XE6’s showing in OSX is not so impressive at first glance, as it is dead last with the¬†two least complicated SVG objects (Clock and Flag) and in¬†the back of the pack with the two more complicated SVG objects. ¬†However, it should be noted that the XE6 is only 5.5 ms (Clock), 3 ms (Car), 4 ms (Watch), and 4 ms (Flag). ¬†Averaging the results, Delphi XE2 is the winner for OSX.

Comparison of execution speed for the FMX RSCL Drawing application (OSX) with Delphi XE2 to XE6

Comparison of execution speed for the FMX RSCL Drawing application (OSX) with Delphi XE2 to XE6

Ratio of Win32 to OSX execution speed for RSCL Drawing apps in Delphi XE2 to XE6 (FMX)

Ratio of Win32 to OSX execution speed for RSCL Drawing apps in Delphi XE2 to XE6 (FMX)

Display of the SVG Clock using FMX TCanvas operations in the OSX test application

Display of the SVG Clock using FMX TCanvas operations in the OSX test application

Display of the SVG Watch using FMX TCanvas operations in the OSX test application

Display of the SVG Watch using FMX TCanvas operations in the OSX test application

The really interesting thing is how fast the OSX implementation is compared to the Win32 implementation. ¬†With the exception of the Clock, the OSX versions clean the Win32 versions clocks (pun unintended ūüôā ), being anywhere from 1.2x-4.2x faster.¬†¬†It must be noted that the Windows box and the Mac Mini are not exactly comparable. ¬†The Mac Mini is an¬†OSX 64-bit Intel¬†I7 @¬†2.3 GHz with 4GB RAM. ¬†Admittedly, the ATI HD 5700 is almost 5 years old now, but the Mac Mini uses integrated graphics. ¬†Examining the outputs closely, there are slight differences in the output (see the dark lines in the Car). ¬†Generally, however, the output from the OSX versions are excellent.

Display of the SVG car using FMX TCanvas operations in the OSX test app

Display of the SVG car using FMX TCanvas operations in the OSX test app

Display of the SVG Flag using FMX TCanvas operations in the OSX test application

Display of the SVG Flag using FMX TCanvas operations in the OSX test application

*Note that Delphi XE3 had visual artificacts drawing the Car and the Watch.  

RSCL Drawing Application, FMX, iOS

Moving to mobile, our drawing times get much slower.  This is expected as the mobile hardware is much slower than the desktop hardware.  For testing iOS apps, we used an iPod Touch with 32GB.  For testing Android apps, we used a Nexus 7 (2013) with 32GB.

Comparison of execution speed for RSCL Drawing App (iOS) from Delphi XE4 to XE6

Comparison of execution speed for RSCL Drawing App (iOS) from Delphi XE4 to XE6

The interesting thing is that Delphi XE5 is the clear winner on iOS in drawing the SVGS.  It is fastest drawing three of the SVGs and only 26 ms (approx. 4%) slower than XE4 when drawing the Car.  Delphi XE6 is the slowest in drawing in iOS.

*Note that Delphi XE4 had minor visual artificacts (gradients) drawing on iOS.  

RSCL Drawing Application, FMX, Android

On an Android device, Delphi XE5 maintains its speed lead over Delphi XE6.  Delphi XE5 is 4-10% faster than Delphi XE6 drawing the SVGs.

Comparison of execution speed for RSCL Drawing App (Android) between Delphi XE5 and XE6

Comparison of execution speed for RSCL Drawing App (Android) between Delphi XE5 and XE6

In the next blog post, we will finish¬†our performance tests with the RSCL Primitives application tests…

Performance Comparison from Delphi 2010 to Delphi XE6 (Part 6c – IECS Mobile App)

IECS Mobile App Execution (Speed) Tests

On the previous two pages, we looked at the Inference Engine Component Suite (IECS) Advanced Console speed tests and the IECS Basic Console speed tests on Win32, Win64, and OSX.  Our final IECS Speed tests are with the IECS Mobile app running on iOS and Android.  The IECS Mobile app provides the simple GUI console for executing expert systems on iOS and Android.  This app executes expert systems and can optionally send output to a TMemo.  It is much closer to the Basic Console than to the Advanced Console so we expect to see similar performance patterns to the IECS Basic Console.

IECS Mobile App, FMX, iOS

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.  As with the Hello World Mobile App, we tested our mobile app on an iPod Touch.

Comparison of execution speed for IECS Mobile App (iOS) between Delphi XE4 and XE6

Comparison of execution speed for IECS Mobile App (iOS) from Delphi XE4 to XE6

Delphi XE6 makes a very good showing on iOS.  It manages the fastest non-visual speed (no updates), being a 1/4 second faster than XE5 and over 2.5 seconds faster than XE4.  With live updates turned on, Delphi XE6 puts in a respectable second place finish.  Delphi XE4 dominates with live updates and finishes in 14.1 seconds compared to 18.2 seconds with XE6 and compared to the embarrassingly awful 50.3 seconds with XE5.

IECS Mobile App, FMX, Android

Since Delphi XE5, Delphi has supported deploying to Android devices.  In Android, Delphi XE5 has to plead no contest again.  While Delphi XE6 is only approximately 9% faster with no updates, once the TMemo is turned on, Delphi XE6 is twice as fast as Delphi XE5.

Comparison of execution speed for IECS Mobile App (Android) between Delphi XE5 and XE6

Comparison of execution speed for IECS Mobile App (Android) between Delphi XE5 and XE6

Coming up next week…

Well, that is it for this week.  The three IECS test applications showed the strength of Delphi XE4 and Delphi XE6.  In our final post, we are going to perform speed tests using the RiverSoftAVG SVG Component Library(RSCL).  The RSCL will only test Delphi XE2 through XE6 and will concentrate on FMX.  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 finding these blog posts informative.  Until next time, Happy CodeSmithing!

 

Performance Comparison from Delphi 2010 to Delphi XE6 (Part 6b – IECS Basic Console)

IECS Basic Console Execution (Speed) Tests

On the previous page, we looked at the Inference Engine Component Suite (IECS) Advanced Console speed tests.  The second IECS test application is the IECS Basic Console application.  As mentioned, the output in the Basic Console can be controlled from a combobox: Live Updates print all output immediately as it occurs, Defer Updates defers all output until the current command is finished by surrounding output in BeginUpdate/EndUpdate, and No Updates suppresses all output and will just write execution time to a status bar. This application is about getting the GUI out of the way and benchmarking non-visual performance with minimal GUI updates.  However, as we will see, even a little output to a TMemo wrapped in BeginUpdate/EndUpdate calls can have significant performance penalties, especially in FMX.

IECS Basic Console, VCL, Win32

As expected, our first tests in Win32 VCL revealed that No Updates executions are fastest, deferring updates are next, and live updates are the slowest.  However, with the VCL TMemo, the differences are relatively minor with no updates being only about twice as fast.  There is one surprise though: Delphi XE6 is slightly but consistently faster than all other versions of Delphi tested.  There is a 16-27 ms difference between Delphi XE6 (fastest) and Delphi 2010 (slowest).  Since the IECS uses generics extensively and generics were still relatively immature in Delphi 2010 (only being introduced in Delphi 2009), perhaps this explains the differences we see.

Comparison of execution speed for executing expert systems in the VCL IECS Basic Console application (Win32) with Delphi 2010 to XE6

Comparison of execution speed for executing expert systems in the VCL IECS Basic Console application (Win32) with Delphi 2010 to XE6

IECS Basic Console, VCL, Win64

When we move up to 64 bits, Delphi XE6 keeps its lead and is faster than all other Delphi versions in all modes (except for a tie with Delphi XE2 when deferring updates).

Comparison of execution speed for executing expert systems in the VCL IECS Basic Console application (Win64) with Delphi 2010 to XE6

Comparison of execution speed for executing expert systems in the VCL IECS Basic Console application (Win64) with Delphi 2010 to XE6

Ratio of Win64 to Win32 execution speed for IECS Basic Console in Delphi XE2 to XE6 (VCL)

Ratio of Win64 to Win32 execution speed for IECS Basic Console in Delphi XE2 to XE6 (VCL)

Examining the ratio of Win64/Win32 doesn’t reveal much. ¬†Win64 is¬†marginally faster than Win32 with live updates and marginally slower with no updates.

IECS Basic Console, FMX, Win32

With the FMX version of the IECS Basic Console, things get more interesting. ¬†In Win32, the Delphi XE4 version scales the best from no updates to defer updates to live updates. ¬†Delphi XE6 has a strong showing being second fastest (only 6 ms behind XE2)¬†with no updates, fastest with defer updates, and second fastest with live updates. ¬†As usual, Delphi XE5 does well if we don’t have to actually output anything. ¬†As soon as live updates are turned on, Delphi XE4 is over 4x faster.

Comparison of execution speed for the FMX IECS Basic Console application (Win32) with Delphi XE2 to XE6

Comparison of execution speed for the FMX IECS Basic Console application (Win32) with Delphi XE2 to XE6

IECS Basic Console, FMX, Win64

Moving up to 64-bit FMX, Delphi XE6 continues to do well.  It is only 2.6 ms behind XE2 (within error margins) when there are no updates, a solid 23 ms ahead when deferring updates, and second fastest (101 ms behind) when live updates are on.  Delphi XE4 is commanding when live updates are on and very strong otherwise.  Delphi XE5 is dragged down by its slow TMemo output.

Comparison of execution speed for the FMX IECS Basic Console application (Win64) with Delphi XE2 to XE6

Comparison of execution speed for the FMX IECS Basic Console application (Win64) with Delphi XE2 to XE6

Looking at the ratio of Win64/Win32, there are no clear patterns shown.  Delphi XE3 is always faster in Win32 versus Win64.  Both Delphi XE2 and XE6 manage to gain speed when outputting to the memo, whether live or deferred.  Delphi XE5 manages to do significantly better in Win64 when doing live updates to the memo.

Ratio of Win64 to Win32 execution speed for IECS Basic Console in Delphi XE2 to XE6 (FMX)

Ratio of Win64 to Win32 execution speed for IECS Basic Console in Delphi XE2 to XE6 (FMX)

IECS Basic Console, FMX, OSX

Moving to the Mac, Delphi XE4 is our winner, managing strong showings in all modes.  Without updates all versions of Delphi are essentially tied (XE6 ekes out 4.5 ms victory).  When we start deferring updates, XE2 and XE3 fall behind.  The surprising result is that when we turn on live updates, Delphi XE2 performs as poorly as XE5.

Comparison of execution speed for the FMX IECS Basic Console application (OSX) with Delphi XE2 to XE6

Comparison of execution speed for the FMX IECS Basic Console application (OSX) with Delphi XE2 to XE6

Like with the IECS Advanced Console, when we look at the ratio of Win32/OSX, the Win32 versions absolutely destroy the OSX versions and are 2x-5x faster.¬† Delphi XE2 shows the largest difference. ¬†Delphi XE4 manages the “best” parity between the Win32 and OSX version, with the Win32 version being “only” a little more than twice the speed of the OSX version.

Ratio of Win32 to OSX execution speed for IECS Basic Console in Delphi XE2 to XE6 (FMX)

Ratio of Win32 to OSX execution speed for IECS Basic Console in Delphi XE2 to XE6 (FMX)

On the next page, we look at the IECS Mobile app speed tests

Performance Comparison from Delphi 2010 to Delphi XE6 (Part 6a – IECS Advanced Console)

IECS Advanced Console Execution (Speed) Tests

The first Inference Engine Component Suite (IECS) application we will start with is the IECS Advanced Console application.  As mentioned, this application should provide a good mix of non-visual benchmarks with updates to TListBoxes and output to a TMemo and tests Win32, Win64, and OSX.

IECS Advanced Console, VCL, Win32

The IECS Advanced Console Win32 VCL speed tests closely mirror the Hello World VCL Win32 speed results.  All versions complete the tests in around 1.2 seconds with only 0.03 second difference between the winner (Delphi XE) and the loser (Delphi 2010).  The differences are essentially meaningless.  According to these test results, no significant compiler works has probably occurred between Delphi 2010 and XE6 (at least for Win32).

Comparison of execution speed for executing expert systems in the VCL IECS Advanced Console application (Win32) with Delphi 2010 to XE6

Comparison of execution speed for executing expert systems in the VCL IECS Advanced Console application (Win32) with Delphi 2010 to XE6

Comparison of EXE size for the VCL IECS Advanced Console application (Win32) with Delphi 2010 to XE6

Comparison of EXE size for the VCL IECS Advanced Console application (Win32) with Delphi 2010 to XE6

Of more interest, the IECS application EXE sizes show the same ballooning of application size as the Hello World application.

IECS Advanced Console, FMX, Win32

Since the Win32 VCL results were so similar, we decided to skip doing Win64 VCL results and go directly to examining IECS Advanced Console Win32 FMX speed tests.  With the IECS Advanced Console running all of those expert system consecutively, we would expect the Delphi versions that did well with small number of items in TListBox (e.g., XE2 and XE3) and with a moderate number of lines added to a TMemo without BeginUpdate/EndUpdate calls (e.g., XE4 and XE6) should do best.  Since there are 4 listboxes (one each for Agenda, Facts, Fact Templates, and Rules) versus 1 memo, XE2 and XE3 should be the winner.  This is what we see, Delphi XE3 is fastest.  Delphi XE2 is hurt by its poor TMemo performance and almost loses second place to Delphi XE6.  Delphi XE5 is the clear loser with its abysmal TMemo performance making it 2.5x slower than XE3.  

Comparison of execution speed for the FMX IECS Advanced Console application (Win32) with Delphi 2010 to XE6

Comparison of execution speed for the FMX IECS Advanced Console application (Win32) with Delphi XE2 to XE6

*Note the Delphi XE6 is “helped” because we had to disable the Memo1.GoToTextEnd statement after every addition to the TMemo, which causes a guaranteed access violation in XE6 (without updates). ¬†This operation incurs some cost and by not having it, Delphi XE6 manages to beat XE4.

Comparison of EXE Sizes for the FMX IECS Advanced Console application (Win32) with Delphi 2010 to XE6

Comparison of EXE Sizes for the FMX IECS Advanced Console application (Win32) with Delphi XE2 to XE6

The EXE size closely tracks Hello World FMX Win32 sizes, with every version getting bigger except for the oversized EXE sizes produced by Delphi XE3.  These differences hold true for all applications.  For the rest of these blog posts, we are not going to compare EXE size anymore.

IECS Advanced Console, FMX, Win64

The same pattern of results holds for the 64-bit version of the IECS Advanced Console application running on a Windows 7 64-bit box.  Delphi XE3 is fastest.  Delphi XE2 is hurt by its poor TMemo performance and almost loses second place to Delphi XE6.  Delphi XE5 is the clear loser with its abysmal TMemo performance making it 2.5x slower than XE3.  If we compare the ratio of Win64 execution speed to Win32 execution speed, we see that Delphi XE2, XE5 and XE6 all improve their speed in Win64.  For some reason, Delphi XE3 and XE4 are slower in Win64 than their Win32 counterparts.

Comparison of execution speed for the FMX IECS Advanced Console application (Win64) with Delphi 2010 to XE6

Comparison of execution speed for the FMX IECS Advanced Console application (Win64) with Delphi XE2 to XE6

Ratio of Win64 to Win32 execution speed for IECS Advanced Console in Delphi XE2 to XE6 (FMX)

Ratio of Win64 to Win32 execution speed for IECS Advanced Console in Delphi XE2 to XE6 (FMX)

IECS Advanced Console, FMX, OSX

Interestingly, when we test the IECS Advanced Console on OSX, the pattern is broken.  Delphi XE3 is still fastest.  However, Delphi XE6 is now second and XE4 third.  

Comparison of execution speed for the FMX IECS Advanced Console application (OSX) with Delphi 2010 to XE6

Comparison of execution speed for the FMX IECS Advanced Console application (OSX) with Delphi XE2 to XE6

As we mentioned in Part 4, the Windows machine used for testing is not exactly comparable to the Mac Mini.  However, the Windows Machine specs (Windows 7 64-bit Intel I7 930 @ 2.8 GHz CPU, and 6 GB RAM) are *close* to the Mac Mini specs (OSX 64-bit Intel I7 @ 2.3 GHz with 4GB RAM), so it will be interesting to do comparisons of the FMX Win32 vs FMX OSX IECS.

Ratio of Win32 to OSX execution speed for IECS Advanced Console in Delphi XE2 to XE6 (FMX)

Ratio of Win32 to OSX execution speed for IECS Advanced Console in Delphi XE2 to XE6 (FMX)

The Win32 versions absolutely destroy the OSX versions and are 2x-4x faster.  The poor TMemo performance on OSX significantly hurts the OSX applications. On the next page, we examine the IECS Basic Console speed tests

Performance Comparison from Delphi 2010 to Delphi XE6 (Part 6 – IECS)

IECS Execution (Speed) Tests

So far, we have been testing the various Delphi versions using a simple Hello World application (described in the Introduction). ¬†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). This¬†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.

About the IECS Test Applications

The IECS test applications use the IECS components to solve expert systems, both with Fuzzy Logic and without.  We are actually testing 3 demo projects that come with the IECS: IECS Advanced Console application (both VCL and FMX), IECS Basic Console application (VCL and FMX), and an IECS Mobile app (FMX for iOS and Android).

Inference Engine Component Suite Advanced Console Screenshot

Inference Engine Component Suite Advanced Console Screenshot

The IECS Advanced Console Application provides a GUI console for interacting and building expert systems.  It contains input and output windows and listboxes that display the list of facts, fact templates, rules, and agenda items currently active in the inference engine.  This application should provide a good mix of non-visual benchmarks with updates to TListBoxes and output to a TMemo and tests Win32, Win64, and OSX.  Note that this is not a console program in the Delphi sense, but a console for interacting with the expert system. The IECS Basic Console Application provides a very simple GUI console for interacting and building expert systems.  There is an input TEdit and an output TMemo, but no TListBox. The output can be controlled from a combobox: Live Updates print all output immediately as it occurs, Defer Updates defers all output until the current command is finished by surrounding output in BeginUpdate/EndUpdate, and No Updates suppresses all output and will just write execution time to a status bar.

Inference Engine Component Suite Basic Console Screenshot

Inference Engine Component Suite Basic Console Screenshot

This application is about getting the GUI out of the way and benchmarking non-visual performance with minimal GUI updates.  However, as we will see, even little output to a TMemo wrapped in BeginUpdate/EndUpdate calls can have significant performance penalties, especially in FMX.  This application is for Win32, Win64, and OSX.  Note that this is not a console program in the Delphi sense, but a console for interacting with the expert system. The IECS Mobile app provides the simple GUI console for executing expert systems on iOS and Android.  This app executes expert systems and can optionally send output to a TMemo.

Inference Engine Component Suite Mobile App Screenshot

Inference Engine Component Suite Mobile App Screenshot

Upon execution, all 3 applications execute a battery of expert system problems:

  • Monkey and Banana Problem – Determine steps for monkey to eat a banana based on moving around a room, stacking furniture, etc to get to banana
  • Word Game problem (GERALD + DONALD = ROBERT)
  • Stacking¬†Problem – Determine plan for stacking one block onto another
  • Sticks Game ¬†– Win the game by removing¬†1 to 3 sticks per turn (from a starting pile of sticks) to leave opposing player with 1 stick at end (only in desktop simulations)
  • Home Recommendation – return scores for different cities based on customer choices for average temperature, population, etc using fuzzy logic
  • Product Design Match – returns scores for different products based on customer choices for cost and size using fuzzy logic
  • Backorders – Simple calculation of backorders based on fuzzy customer order amounts (low, high, medium)
  • Game Combs – Decide aggressiveness based on enemy health, our health, and distance
  • Project Risk – Determine how risky a project is based on accumulation of evidence of duration, staffing, funding, complexity, priority, and visibility using fuzzy logic

The IECS Advanced and Basic Console applications load the expert systems from the file system.  The IECS Mobile App has the expert systems embedded in the app in a TClientDataSet. This is a large blog post, so we have divided the speed tests into 3 sub-parts: