Updated: Benchmarking Oxygene Island versus Delphi, C/C++, and .NET

Calculating 50000 digits of Pi, computation time (in sec)
------------------------------32 bit----------------------------- 64bit
Delphi Rio ----------------35.019--------------------------- 33.791
Visual C/C++ ------------33.399----------------------------33.453

So the good news is: In the context of this limited testing, Oxygene/Island can generate equally (actually, slightly faster) optimized code as Visual C/C++!

The following is detailed story.

Attracted by the proud words from RemObject about its Island product and the “native CPU power”, I acquired a personal version, with the goal to find out a performant native Pascal compiler for computationally-intensive scientific applications. I’d like to know if Oxygene/Island fits.

Here are the test settings:

  • Delphi Rio
  • Island/Oxegene
  • Visual C/C++ 2017, with optimization switch favor faster code
  • All test are compiled on Windows Server 2016 x64 OS.
  • The testing code is based on the following Free Pascal code, which is trivially ported into Delphi, Oxygene/.NET, Oxygene/Island, and C respectively.

For the computational performance, it is (loosely) assumed that Oxygene/Island should spit out better optimized code. than Delphi, given it is LLVM-based.

For Delphi and Island, the Win32 API QueryPerformanceCounter is used to measure time; while for Oxygene/.NET, the .NET stock StopWatch is used.


1. Size of the executable:

Oxygene/Island (32bit)

  • Debug Build: 1.54MB
  • Release build: 526KB


  • Debug Build: 90KB
  • Release build: 90KB

Delphi Rio 10.3 (32bit)

  • Debug Build: 963KB
  • Release build: 59.5KB

Visual C/C++ (2017)

  • Debug Build: 13KB
  • Release build: 12KB

2. Computation time to calculate 50000 digits of Pi


  • **Release build: 33.316 sec (32bit) 33.434sec (64bit)


  • Release build: 33.818 sec

Delphi Rio 10.3

  • **Release build: 35.019 sec (32bit) 33.791(64bit)

Visual C/C++ (2017)

  • **Release build: 33.3995 sec (32bit) 33.4529(64bit)

CONCLUSION - Oxygene Island 32bit build is about 5% faster than Delphi 32bit native code, but it generates almost 10x LARGER executable. When it comes to 64bit built, the difference is very small (~1%), 33.434 sec (Island) versus 33.791 sec (Delphi).

Also finally - Compiling Time (if you do care about it) - for this little program (< 80 lines)
Oxygene/Island compiling time: 4.29 sec
Delphi compiling time: 0.9 sec

Updated - for those interested, the little testing code is at this Gist link:



I tried the sample code you posted before editing. I also see 5% faster performance for Island.
The difference in size is most likely due to the garbage collector code.
In Delphi you are only including the Windows unit. Once you start adding more units the size will grow considerably. There are only a few cases that I see my Delphi programs to be smaller than the equivalent Island ones.

About the performance, there is more potential to gain in Island. Once you have code that deals with memory management, the GC use to perform better than freeing memory in each loop pass. Also, parallel programming is way easier in Oxygene.


If we are going into details regarding memory management and threading one advantage I see on Delphi is how easy is to test and try different memory managers and threading libraries.

Memory managers like FASTMM4 with specific switches e.g. UseReleaseStack, or SCALEMM2 can make huge differences. On the other hand Prizmos OTL Parallel library is extremly solid and with great support.

Once you go into big scalable systems on .Net you have to deal with GC issues, like the famous GC pauses and rely on .Nets memory control. Same goes for database drivers, etc. Delphi allows you a bit more control over all those, but with the additional cost of having to take care of things on your own.

.Net gives you that care free attitude that is useful on big projects share with a lot of developers where skill levels are mixed. Another example are Memory tables, I havent found anything faster than (Delphi)Kbmmw’s memory tables on the .Net workd, etc, etc. I guess it will depend on your objective.

1 Like

Just a side note:

In .NET world one just have to be aware of possible GC caveats while writing a high-loaded code. It is very easy to write an innocent-looking code that will stress the memory management system badly, while change in just one line of that code might decrease time spent in GC from 20% of execution time to less than 1%. Note that modern implementation of .NET GC can run in background most of the time significantly reducing the the application threads latency.


Oxygene/Island uses Garbage Collection? As it targets native CPU, how is Island‘s GC compared to .NET GC?

Island uses the boehm gc currently. Though the gc is swappable.

1 Like