Document text extraction is a foundational capability for data security analysis. Its processing efficiency and resource usage directly affect the cost of associated tasks. As document-processing requirements grow, engine optimization must address content completeness, processing latency, and computational demand together, with benefits verified under consistent measurement conditions.
The document processing engine refactoring targets shorter processing times, lower CPU cost, and lower per-task peak memory usage. The performance evaluation compares the refactored implementation, the previous implementation, and Apache Tika using the same document set, covering DOCX, XLSX, PPTX, and PDF.
Under a separate process per document, including startup and initialization costs, the refactored implementation reduced cumulative elapsed time by approximately 93.0%, cumulative CPU time by 94.3%, and the maximum single-task peak working set per round by 67.7%, relative to the previous implementation. These reductions apply to the tested workload and measurement model, not to whole-system resource consumption or every deployment scenario.
Performance gains
The test set contains 12 generated documents, with three sizes per format. Each implementation completed six measured rounds. The table reports the median across those rounds.
Elapsed time and CPU time are summed separately over the 12 tasks in each round. The memory metric takes the highest single-task peak in each round, followed by the median over six rounds; memory usage is not added across tasks. The elapsed-time totals consist of independent tasks executed in rotating order, not a throughput measurement of continuous processing in a persistent service.
Relative to Apache Tika in this test configuration, the corresponding reductions were approximately 95.0%, 98.8%, and 88.7%. Apache Tika serves only as an external reference. These results do not evaluate other versions or deployment configurations.
Document processing time
For all 12 test inputs, the refactored implementation recorded a lower median elapsed time per task than either reference. This demonstrates shorter processing wait times under the short-lived task model used in this evaluation.
The improvement varies by format. The previous implementation had comparatively low elapsed times for presentations, while its PDF elapsed times grew more noticeably as page count increased within this set. The best result for a single format is therefore insufficient to characterize every document.
The measurement includes initialization, text extraction, and result output. Their individual contributions were not measured separately, so the total improvement cannot be attributed to a specific stage or technology choice.
CPU cost
Processing latency and computational cost are distinct metrics. Parallel execution can reduce elapsed time while increasing cumulative CPU time; both were therefore recorded.
For the same set of 12 tasks, median cumulative CPU time decreased from 9.930 s for the previous implementation to 0.570 s for the refactored implementation. This supports a reduction in cumulative computation for the tested workload.
CPU time is not whole-system CPU utilization and cannot be converted directly into energy consumption or battery-life changes. Whole-system utilization, energy use, and battery life were not measured, and no corresponding inference is made.
Per-task peak memory
The median of the maximum single-task peak working set per round decreased from 111.90 MiB for the previous implementation to 36.18 MiB for the refactored implementation. This metric is the largest resident working set recorded by the operating system for a process. It includes the runtime environment and shared resident pages and is not equivalent to private memory or whole-system memory usage.
Memory growth differs by format. It was more pronounced for the spreadsheets in this set than for the presentations, indicating that resource budgets must account for format and content size. Small-file results cannot be extrapolated directly to large-file behavior.
Lower single-task peaks provide evidence for reducing the resource requirements of document tasks, but do not imply that concurrency can increase proportionally. Concurrent workloads involve overlapping peaks, shared pages, and caches and require independent measurement.
Test conditions and result validation
Testing took place on 20 October 2026 on the same Windows workstation. All three test processes were verified as x64.
The input sizes were 100, 1,000, and 5,000 paragraphs for DOCX; 100, 1,000, and 5,000 rows with six columns per row for XLSX; 5, 50, and 200 slides with 10 paragraphs per slide for PPTX; and 5, 50, and 200 pages with 35 lines per page for PDF. All implementations read identical inputs, with file hashes unchanged before and after testing.
Each document–implementation combination received one warm-up followed by six measured executions, all using fresh processes. Inputs were pre-read without clearing the operating-system file cache. The six rounds covered all six implementation orders, with document order reshuffled using a fixed seed. There were 216 measured executions, plus 36 warm-ups excluded from the statistics. No slow measured executions were discarded.
Each execution checked the success status and compared all alphanumeric body-text tokens in order. Differences in the inclusion of worksheet names were registered before testing and were not treated as body-text differences. All 216 measured executions passed this check; failures, empty text, or missing body content were not counted as faster results. The check does not compare whitespace layout and does not establish behavioral equivalence for complex documents.
CPU time is the sum of process user-mode and kernel-mode time and may exceed elapsed time under multithreading. On this machine, readings advanced in approximately 15.6 ms steps; a zero reading for a short task does not imply zero computation. Memory uses the system-maintained peak-working-set counter rather than estimating the peak solely from periodic samples.
The curves show the median and minimum–maximum range of six runs. Error bars are not confidence intervals, and connecting lines do not extrapolate to unmeasured sizes. Reductions use unrounded medians and the formula “1 − refactored value ÷ reference value.” Reductions in different metrics cannot be added or combined into an overall performance-improvement percentage.
Scope of the results
These results establish elapsed-time, CPU-time, and per-task peak-memory benefits for the tested workload. The separate-process test includes initialization costs, which persistent services can amortize. The reported reductions therefore cannot directly predict persistent-service request latency, parsing speed after warm-up, or sustained throughput.
The samples are generated ASCII-text documents without images, formulas, macros, external resources, or embedded attachments and do not represent the distribution of actual enterprise documents. Legacy formats, Chinese text and complex encodings, unusual fonts, complex tracked changes, encrypted or damaged documents, and PDF watermarking results require separate verification. This evaluation is not a claim of complete behavioral alignment.
Testing covers one workstation and six measured executions per combination, not a cross-hardware or cross-platform performance guarantee. The figures come from an internal NSecsoft benchmark, not independent third-party certification.
Contact
8 min 
