{"id":71,"date":"2013-05-26T03:30:00","date_gmt":"2013-05-26T03:30:00","guid":{"rendered":"http:\/\/evolvedmicrobe.com\/blogs\/?p=71"},"modified":"2014-05-11T13:12:38","modified_gmt":"2014-05-11T13:12:38","slug":"java-vs-c-performance-comparison-for-parsing-vcf-files","status":"publish","type":"post","link":"http:\/\/evolvedmicrobe.com\/blogs\/?p=71","title":{"rendered":"Java vs. C# Performance Comparison for Parsing VCF Files"},"content":{"rendered":"Making a comparison with a reasonably complex program ported between the two languages.\r\n\r\n

Update 3\/10\/2014: After writing this post I changed the C# parser to remove an extra List<> allocation in the C# code that was not in the Java code.\u00a0\u00a0After this, the Java\/C# versions are indistinguishable on speed, but the C# code used ~88 MB of memory while the java version used >1GB.\u00a0 Therefore, I now believe the winner is C# and a fast implementation of this parser (which can be over an order of magnitude faster for certain scenarios not in this test) is available\u00a0here<\/a><\/em><\/p>\r\n\r\nVCF files<\/a> are a popular way to store information about genotypic variation from next generation sequencing studies.\u00a0 The files are essentially large matrices, where each element in the matrix represents a collection of information about the genotype of a particular person at a particular locus in the genome (in this sense, they can be considered as a multi-dimensional matrix in a flat file format).\r\n\r\nThe Java Picard package<\/a> is a common utility used for parsing these files.\u00a0 While parsing, the challenge is to read each line (row) of the file, and construct objects for each element in that row that can then be manipulated or inspected.\u00a0 I just finished translating the Java VCF parser in Picard to C#, and so thought it might be a good chance to compare the two different languages and runtimes.\r\n\r\nC# showed a number of advantages in the translation.\u00a0 The translation itself was mostly a lot of deleting.\u00a0 The get\/set assessors in C# really allowed for the removal of seemingly endless amount of getXXXX\/setXXX methods in Java.\u00a0 It also seemed like every other line in Java was a call to some apache commons class to perform a simple task like get the maximum value in an array, create an empty list, or do a selection on data.\u00a0 Extension methods and Linq have clear advantages for data processing here (though I have found these have a slight overhead relative to the for loop equivalents).\u00a0 Yield statements in Java also would seem to be useful.\r\n\r\nAt the same time, Java had some things that would have been nice in C#.\u00a0 I had to implement basic collection types like immutable hashsets and dictionaries, a LinkedHashSet class as well as an OrderedGenericDictionary during the port.\u00a0 These should be in the C# language.\r\n

Performance<\/h1>\r\n<\/strong>This of course am what I am most interested in.\u00a0 My main computer is broken, so I had to test on my windows desktop at home.\u00a0 For the test, each program would read a gzipped VCF file for 20,000 lines, first creating an initial lazy class representing a portion of the data and then fully decoding this lazy version to represent the complete data as objects.\u00a0 The test file was a VCF with >1,000 individuals, though unfortunately most of these individuals were non-calls at various positions, but its what I had on hand.\r\n\r\nImmediately after porting \u2013 <\/strong>After essentially re-writing the Java in C#, I ran some tests.\u00a0 Both Java and C# can run in either client (low-memory) or server modes.\u00a0 So I did both, here are the results:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
Platform<\/strong><\/td>\r\nVM Options<\/strong><\/td>\r\nWorking Set<\/strong><\/td>\r\nPaged Memory<\/strong><\/td>\r\nTime (s)<\/strong><\/td>\r\n<\/tr>\r\n
Java<\/td>\r\nNone<\/td>\r\n27.8 MB<\/td>\r\n41.32 MB<\/td>\r\n11.5<\/td>\r\n<\/tr>\r\n
.NET<\/td>\r\nNone<\/td>\r\n28.9 MB<\/td>\r\n30.22 MB<\/td>\r\n15.1<\/td>\r\n<\/tr>\r\n
Ratio<\/td>\r\n<\/td>\r\n1<\/td>\r\n1.35<\/td>\r\n0.76<\/td>\r\n<\/tr>\r\n
Java<\/td>\r\nServer<\/td>\r\n362.2 MB<\/td>\r\n414 MB<\/td>\r\n7.4<\/td>\r\n<\/tr>\r\n
.NET<\/td>\r\nServer (GC)<\/td>\r\n126 MB<\/td>\r\n332 MB<\/td>\r\n14.7<\/td>\r\n<\/tr>\r\n
Ratio<\/td>\r\n<\/td>\r\n2.9<\/td>\r\n1.25<\/td>\r\n0.5<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\nA couple noticeable conclusions here. First Java is smoking .NET on performance, but this is essentially Java code at this point and it wasn\u2019t written for C#.\u00a0 Second, there is a massive amount more memory used in server mode, and in Java at least one obtains a large performance win for this cost.\r\n\r\nAfter \u201cSharpening\u201d the code \u2013 <\/strong>The initial port was basically Java, so I cleaned it up a bit after running it through the profiler, here are some notable changes:\r\n