Performance benchmarks typically measure in milliseconds. In production systems, however, milliseconds translate into processing queues, infrastructure requirements, cloud costs, and waiting time for users.

Our previous benchmark tests compared TX Text Control Classic and TX Text Control Core using identical documents and hardware. The results showed that Core is consistently faster at generating DOCX and PDF documents. For PDF generation, Core's performance was approximately eleven times faster than Classic, depending on the document size.

Learn more

With the release of the new core version of TX Text Control, we set out to benchmark its performance against the classic version on both Windows and Linux environments. This comparison provides valuable insights into speed, efficiency and cross-platform capabilities.

Benchmarking TX Text Control: Classic vs. Core on Windows and Linux

But what do these numbers mean in a real application?

This article applies published benchmark results to real-world document processing scenarios, including invoice batches, customer portals, document conversion services, and Azure-hosted workloads.

The Published Benchmark Data

The first benchmark generated DOCX and PDF documents from plain text files of increasing size.

Plain Text to DOCX

In this benchmark, the time taken to generate DOCX documents from plain text files was measured. The results are summarized in the following table:

Core is consistently faster than Classic at generating DOCX documents. The below graph shows the measured processing time for each document size.

Plain Text to PDF

In this benchmark, the time taken to generate PDF documents from plain text files was measured. The results are summarized in the following table:

Core scales particularly well during PDF generation. In the 100,000-line test, it took Classic approximately 159 seconds to complete the same operation, whereas Core finished in approximately 14.5 seconds.

The following graph shows the measured processing time for each document size.

Understanding the Real-World Impact

In production systems, milliseconds translate into processing queues, infrastructure requirements, cloud costs, and waiting time for users. The following scenarios illustrate how benchmark results translate into real-world document processing scenarios.

Scenario 1: Generating Customer Documents on Demand

Consider a web application that generates a PDF when a customer downloads a statement, policy document, quote, or report.

Using the measured results for a 5,000-line PDF:

Customers using Core receive the generated document more than seven seconds earlier.

This difference is clearly visible in an interactive application. A request lasting less than one second may feel immediate. However, a request that takes almost eight seconds may require loading indicators, longer HTTP timeouts, and additional handling for users who repeatedly click the download button.

The faster operation also frees up the processing worker sooner, enabling it to serve the next request.

Scenario 2: Processing an Invoice Batch

Now, consider an ERP system that generates 10,000 invoice PDFs during a billing run.

Using a 5,000-line benchmark document as a model, a sequential worker would need to:

The Core workload finishes approximately 19.9 hours sooner.

This calculation does not imply that each invoice contains precisely 5,000 lines. Real invoice complexity varies. Rather, it shows how the measured processing time difference accumulates when the same operation is repeated on a large scale.

With parallel workers, both totals would decrease. However, Core would still require substantially fewer worker hours to complete the same batch.

Scenario 3: Large Report Conversion

Some applications generate large audit reports, medical documentation, technical manuals, and regulatory records.

For the 100,000-line PDF benchmark, the measured processing times were as follows:

For a batch of 1,000 such documents:

Core reduces the processing time required for this specific workload by approximately 90.9%.

This is where benchmark performance becomes operationally important. A workload that would otherwise occupy a processing instance for nearly two days can now be completed in about four hours using the same benchmarked hardware.

Translating Processing Time into Azure Costs

Azure Virtual Machines are billed based on the selected VM type and how long the VM is provisioned. Similarly, AKS workloads incur compute charges for their underlying virtual machines.

Therefore, the compute cost model is straightforward.

Compute cost = required VM hours x hourly VM price

For the 1,000-document scenario above:

Because both versions are compared using the same assumed VM rate, the percentage difference does not depend on the selected Azure VM.

For example, let R represent the hourly price of the selected Azure instance:

With an hourly rate of $0.20, the modeled compute cost would be about $8.85 with Classic and €0.81 with Core.

At $0.50 per hour, the cost would be about $22.13 with Classic and $2.02 with Core.

These amounts are examples rather than actual Azure prices. Actual Azure costs depend on the VM family, region, operating system, pricing agreement, reservation model, storage, and networking. Azure also offers reserved VM pricing, which can reduce costs compared to pay-as-you-go pricing.

Regardless of the selected rate, the important result is that for this benchmarked workload, Core uses approximately one-eleventh of the processing time and therefore approximately one-eleventh of the compute cost when the instance can be stopped or scaled down after processing.

Scenario 4: Containerized Document Services

A document conversion service may be run in Docker containers or an Azure Kubernetes Service cluster.

Suppose the service needs to process 1,000 documents within a four-hour timeframe. Based on the 100,000-line PDF benchmark:

The worker count is rounded up because it is not possible to deploy partial workers.

This is not a measured Kubernetes benchmark. Rather, it is a capacity calculation based directly on published single-operation timings. The calculation assumes that workers scale linearly and that document processing is the dominant workload.

Real deployments include additional factors such as startup time, storage access, network traffic, orchestration overhead, and concurrency limits. Nevertheless, this calculation shows how a faster document engine can reduce the infrastructure needed to meet the same processing deadline.

Scenario 5: High-Volume DOCX Generation

Not every workflow produces a PDF. Many systems generate editable DOCX documents for contracts, correspondence, case files, and downstream processing.

The published benchmark measured a 50,000-line DOCX document as follows:

For 100,000 generated documents:

Although the performance difference is smaller than for PDF generation, at high volumes, it still eliminates nearly 40 hours of processing time from the modeled workload.

More Than File Export

A separate benchmark tested common document operations on both Windows and Linux.

Inserting an image took 952 milliseconds with Classic and just 40 milliseconds with Core on Windows. The time required for formatting operations decreased from 1,783 milliseconds to 86 milliseconds.

The following graph shows the measured processing time for each operation.

These operations are relevant to template generation, mail merging, document assembly, and automated report creation. A production document is rarely generated by a single export call. It may undergo hundreds of formatting, image, table, and layout operations before being saved.

Accelerating these individual operations can improve the entire processing pipeline.

Why Core Is Faster

Text Control Core is more than just the Classic version compiled for Linux.

Core uses a modern, platform-independent architecture with SVG-based rendering, eliminating dependencies on Windows graphics APIs. This improves portability and reduces rendering overhead in many document processing operations.

The architectural differences are particularly relevant in server and cloud environments.

It provides consistent rendering on Windows and Linux, faster PDF generation, faster image and formatting operations, better suitability for containerized deployments, and more processing capacity from the same computing resources.

Classic remains relevant for traditional Windows applications that require deep integration with Windows-specific APIs and technologies. Core is the preferred architecture for modern, cross-platform, server, Linux, container, and cloud workloads.

Understanding the Limits of These Calculations

The scenarios in this article are projections based on published benchmark timings. They are not independent production benchmarks.

Actual results depend on factors including:

• Document structure and complexity
• Fonts and embedded images
• Available CPU and memory
• Parallel processing strategy
• Storage performance
• Network and database latency
• Container and process startup time
• Azure region and VM type

The calculations intentionally keep the relationship transparent. For example:

1,000 documents x 159.313 seconds = 44.25 processing hours

This allows developers to replace the benchmark duration with their own measured document-processing time and calculate capacity and cost for their specific workload.

Conclusion

A difference measured in milliseconds can add up to hours when document processing is repeated thousands of times.

Based on published tests, TX Text Control Core provides the following:

• Approximately two to five times faster DOCX generation
• Up to approximately eleven times faster PDF generation
• More than 95% lower execution times in tested image and formatting operations
• Comparable performance on Windows and Linux

For a modeled batch of 1,000 large PDFs, the measured results translate to approximately 44.25 hours of sequential processing with Classic and 4.03 hours with Core.

This means shorter batch windows, faster interactive document generation, fewer required processing workers, and potentially substantially lower Azure compute costs.

Performance is not simply about making one document faster. It determines how many documents an application can process, how much infrastructure is required, and how efficiently it can scale.

Frequently Asked Questions