Aug 6, 2007

.Net Vs Java

One of the funny things about computer technology is the bitter industry rivalries that inevitably crop up. There is probably no industry rivalry more bitter or hate-filled than that of .NET and Java.

While it is difficult to quantify definitively which platform is more flexible, easier to use, or easier to learn – we can certainly compare speed. So, havn’t you always wondered – who’s faster: .NET or Java?

Last week, Microsoft released .NET 2.0, the long-awaited major-upgrade to .NET 1.1 – coinciding with the releases of Visual Studio 2005 and SQL Server 2005. Armed with this new software, we set out to determine which is faster - .NET 2.0 or Java 1.5.

Test 1 – Selection Sort

Our first test will utilize the age-old textbook problem of computer sorting algorithms. To thoroughly stress-test the two technology platforms, we chose a highly inefficient sorting algorithm – selection sort. Selection sort is a method of sorting a list of items, typically numeric in nature, from say highest to lowest. Because Java and C# are quite similar we were able to use the same selection sort code with extremely minor modification in Java and C#.

Selection sort is considered to be an inefficient sorting algorithm because its complexity in computer science terms is order n2. This means that if you want to sort a list of 1,000 numbers it will take as many as 1,000,000 steps. We chose selection sort because of its easy portability between C# and Java and – precisely because of its inefficiency and corresponding heavy use of memory – it will help to highlight any performance differences the two platforms.

The following system was used as a testbed:




Pentium D 3.0 Ghz, 2 MB Cache



Operating System

Windows XP Professional SP2 (Latest Patches, x32)

.NET Version


Java Version

1.5.0 (J2SE)

Hard Disk (Not Important)

2x 250 GB 7200 RPM

So – you must be anxious to see the results. Below is shown the running time in milliseconds of an ascending selection sort on a set of 1,000 descending floating point (double) numbers (the same data was used for .NET and Java). Since this is running time, obviously less time is better.

Selection Sort on 1,000 Floating Point Elements, Time in MS

Now comes the interesting step – let’s scale the dataset up to 100,000 elements, pushing the complexity up to 10,000,000,000 steps:

Selection Sort on 100,000 Floating Point Elements, Time in MS

It looks like Test 1 has a clear winner - .NET 2.0. Interestingly, the same general proportions between completion times for the two platforms remains similar – hence the same proportions portrayed in the graphs, despite the drastic increase in input size. In the larger test, Java required 36,828 ms to complete the job, while .NET took 21,375 ms; .NET required only 58% of the time required by Java to complete the same task. That’s nearly 2-to-1.

Test 2 – Memory Efficiency

One feature of managed code is dynamic, and automatic, memory management. While easing the complexities of the development process by abstracting out memory management significantly, memory managers add overhead. Both .NET and Java use more memory to store the same data in RAM than the venerable C/C++.

In this test, we will pit the memory managers of Java against .NET in comparative memory allocation tasks under Windows XP.

The first comparison compares the memory required to allocate 100,000 floating point elements (double). Please note that this first test is meant more as a baseline to establish how much base memory overhead there is than as a direct comparison:

Baseline Memory Comparison

Memory was measured by computing the total amount of memory used by the process. Here, things are fairly close. The double type in Java 1.5 is a 64-bit IEEE 754 value, while in .NET the double data type is also a 64-bit IEEE-compliant value. The memory was allocated in an array structure. This array was initialized with values to ensure that real rather than "virtual" memory was allocated. Now that we have established an overhead baseline, let’s up the number of elements to 5 million:

Memory Comparison 2

Again, we have a clear winner – Java 1.5. Note that all of our graphs start at zero to give as fair a comparison as possible. .NET is using more than twice the amount of memory Java uses to store the same amount of data – 19.9 MB versus a whopping 47.8.

Test 2 – Memory Efficiency, Continued

To further experiment with memory efficiency, we expanded the memory test to include an array of classes. Classes, as you probably know, are the foundation of object oriented programming, and virtually all modern software uses them in some capacity. As .NET and Java are both heavily object-oriented, the efficiency with which the two platforms can allocate objects is very important.

In this test we allocate and initialize 500,000 objects of type DataTestObject. DataTestObject encapsulates some data about a fictional bank account. The class is simple enough that it is easily portable from C# to Java with only slight modification. We also make use of two system types – strings and times:

public class DataTestObject
public double BankBalance;
public string BankAccountID;

string CustomerFirstName;
public string CustomerLastName;

DateTime MostRecentWithdrawal;

public DataTestObject()
BankBalance = 0.0;
BankAccountID = "DHC116A-111908-5";
CustomerFirstName = "Jon";
CustomerLastName = "Doe";
MostRecentWithdrawal = DateTime.Now;

public void UpdateBalance(double d)
BankBalance += d;

This class contains two functions, which perform operations on the object, as well as five fields for storing data. An array of 500,000 of these objects is created and initialized.

Class Memory Usage
Class Memory Usage

Here we see .NET reversing the memory outlook and besting Java by a solid margin. This indicates that since .NET treats native types – such as double – as objects, that this incurs additional overhead of some form. Java, on the other hand, does not treat native types as objects and therefore can save on this overhead. However, when it comes to real-world object allocation, it appears that .NET is more efficient.


Thus, as we have seen, .NET 2.0 won 2 out of the 3 major tests – clearly besting Java 1.5 in both execution speed and real-world memory efficiency. Java did, however, manage to hold its own in the native types memory comparison by a pretty wide margin. This indicates that on the whole .NET is a more efficient platform, with perhaps at least one area for improvement – native type memory efficiency.

So now that we have seen that .NET is more efficient by what appears to be a constant factor, the question remains – does it matter? The fact is that, despite the many advantages offered by managed code platforms like .NET and Java, most applications are still written in C++/COM. Consider the following random list of popular applications:

  • Microsoft Office
  • Internet Explorer
  • iTunes
  • Windows Media Player
  • FireFox
  • Photoshop

These applications are almost completely C++ and COM – no managed code. So it’s pretty clear that companies and organizations that have invested heavily in an existing code base are not about to throw that code out the window. However, .NET and to a limited extent, Java, can interoperate with existing code and many new features and addons to popular existing software, such as those listed above, are being implemented in managed code.

Clearly, a big part of this industry-wide transition towards managed code will hinge on improvements in execution speed and memory efficiency – specifically in Java and .NET.

It appears that Microsoft .NET has not only caught up to Java in many ways, but it has surpassed it in terms of implementation efficiency. This is not surprising since Microsoft continues to prosper while Sun appears to be in a slow decline as businesses move away from expensive, proprietary systems. This is not to say that Java should be discarded completely, but we have a clear efficiency champion in .NET.

Source :