Benchmark

We tested the performance and memory allocation when parsing X12 834 small and large files using the .NET Core 3.1 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 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):

[Splitter]
[DataMember]
[Required]
[Pos(7)]
public virtual List<Loop_2000_834> Loop2000 { get; set; }

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", 
      new X12ReaderSettings { Split = true }))
   {
      while (ediReader.Read())
      {
      }
   }
   watch.Stop();
   Console.Write(watch.ElapsedMilliseconds);
   Console.ReadKey();            
}

System Setup

EdiFabric.Framework 9.8.7.4

EdiFabric.Core 9.8.7.4

BenchmarkDotNet=v0.12.0

OS=Windows 10.0.18363

Intel Core i7-9700 CPU 3.00GHz, 1 CPU, 8 logical and 8 physical cores

.NET Core SDK=3.1.402

[Host] : .NET Core 3.1.8 (CoreCLR 4.700.20.41105, CoreFX 4.700.20.41903), X64 RyuJIT

The Results

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

- Large file, 22.8 MB, 100 000 employee enrollments, no splitting  

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

The Verdict

 The results clearly show that:

• A small 834 transaction is parsed for ~ 5 milliseconds.
• 100 000 employee enrollments are processed for 40 seconds with gradual memory increase, peaking at 382 MB, when no splitting is used.
• 100 000 employee enrollments are processed for 43 seconds with constant memory at 25 MB when splitting by Loop 2000.