Benchmark Setup

We tested the performance and memory allocation when parsing X12 834 small and large files using the .NET Core 2.0 version of X12 Reader.

Small file

We used BenchmarkDotNet (default settings) to benchmark an X12 5010 834 transaction with 2 employee enrollments. (Download test file)

The original sample file was taken from EDI Academy.

The code we used is (file reading is included in the measurement):

[MemoryDiagnoser]
public class EdiParserBenchmark
{
   [Benchmark]
   public static void Run() 
   {
      var edi = File.OpenRead(@"C:\Hipaa_834.txt");
      using (var ediReader = new X12Reader(edi, "EdiFabric.Templates.Hipaa"))
      {
          while (ediReader.Read())
          {
          }
      }
   }
}

Large file

We used .NET Stopwatch to benchmark a large X12 5010 834 transaction with 100 000 employee enrollments. (Download test file)

The original sample file was taken from EDI Academy. We copied the first employee 100 000 times to produce the large file.

We measured both regular parsing and with segments splitting (on Loop 2000).

The code we used is (file reading is included in the measurement):

public static void Run()
{
   Stopwatch watch = Stopwatch.StartNew();
   var edi = File.OpenRead(@"C:\Hipaa_834_Large.txt");
   using (var ediReader = new X12Reader(edi, "EdiFabric.Templates.Hipaa"))
   {
      while (ediReader.Read())
      {
      }
   }
   watch.Stop();
   Console.Write(watch.ElapsedMilliseconds);
   Console.ReadKey();            
}

System Setup

EdiFabric.Framework 9.7.4

EdiFabric.Core 9.7.4

BenchmarkDotNet=v0.10.14

OS=Windows 10.0.17134

Intel Core i7-7700HQ CPU 2.80GHz (Kaby Lake), 1 CPU, 8 logical cores and 4 physical cores

Frequency=2742186 Hz

Resolution=364.6726 ns

Timer=TSC

.NET Core SDK=2.1.105

[Host]

: .NET Core 2.0.7 (CoreCLR 4.6.26328.01, CoreFX 4.6.26403.03), 64bit RyuJIT

: .NET Core 2.0.7 (CoreCLR 4.6.26328.01, CoreFX 4.6.26403.03), 64bit RyuJIT

The Results

1. Small file, 1 KB, 2 employee enrollments, no splitting

   Method	Mean	Error	StdDev	Gen 0	Allocated
   Run	7.147 ms	0.0421 ms	0.0351 ms	507.8125	1.02 MB

   
2. Large file, 22.8 MB, 100 000 employee enrollments, no splitting

   Method	Elapsed	Allocated at start	Allocated at end
   Run	110680 ms	1 MB	282 MB

3. Large file, 22.8 MB, 100 000 employee enrollments, splitting by Loop 2000

   Method	Elapsed	Allocated at start	Allocated at end
   Run	106761 ms	1 MB	15 MB

The Verdict

 The results clearly show that:

• A small 834 transaction is parsed for ~ 7 milliseconds.
• 100 000 employee enrollments are processed for 1 minute and 50 seconds with gradual memory increase, peaking at 282 MB, when no splitting is used.
• 100 000 employee enrollments are processed for 1 minute and 47 seconds with constant memory at 15 MB, when splitting by Loop 2000. Processing files with splitting is the clear winner when it comes to large files and preserving system resources.