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.<\/p>\n

\n\n\n\n\n\n\n\n

Metric<\/span><\/th>\n

Refactored implementation<\/span><\/th>\n

Previous implementation<\/span><\/th>\n

Apache Tika 3.3.0<\/span><\/th>\n<\/tr>\n<\/thead>\n

Cumulative elapsed time for 12 tasks<\/span><\/td>\n

0.724 s<\/strong><\/span><\/td>\n

10.326 s<\/span><\/td>\n

14.528 s<\/span><\/td>\n<\/tr>\n

Cumulative CPU time for 12 tasks<\/span><\/td>\n

0.570 s<\/strong><\/span><\/td>\n

9.930 s<\/span><\/td>\n

46.250 s<\/span><\/td>\n<\/tr>\n

Maximum single-task peak working set per round<\/span><\/td>\n

36.18 MiB<\/strong><\/span><\/td>\n

111.90 MiB<\/span><\/td>\n

320.15 MiB<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

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<\/strong>. The elapsed-time totals consist of independent tasks executed in rotating order, not a throughput measurement of continuous processing in a persistent service.<\/p>\n

Relative to Apache Tika in this test configuration, the corresponding reductions were approximately 95.0%, 98.8%, and 88.7%<\/strong>. Apache Tika serves only as an external reference. These results do not evaluate other versions or deployment configurations.<\/p>\n

Document processing time<\/strong><\/h4>\n
$\"Ping64,Elapsed$ <\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
CPU cost<\/strong><\/h4>\n
$\"Ping64,Cumulative$ <\/p>\n
Processing latency and computational cost are distinct metrics. Parallel execution can reduce elapsed time while increasing cumulative CPU time; both were therefore recorded.<\/p>\n
For the same set of 12 tasks, median cumulative CPU time decreased from 9.930 s<\/strong> for the previous implementation to 0.570 s<\/strong> for the refactored implementation. This supports a reduction in cumulative computation for the tested workload.<\/p>\n
CPU time is not whole-system CPU utilization<\/strong> 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.<\/p>\n
Per-task peak memory<\/strong><\/h4>\n
$\"Ping64,Peak$ <\/p>\n
The median of the maximum single-task peak working set per round decreased from 111.90 MiB<\/strong> for the previous implementation to 36.18 MiB<\/strong> 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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Test conditions and result validation<\/strong><\/h4>\n
Testing took place on 20 October 2026 on the same Windows workstation. All three test processes were verified as x64.<\/p>\n
\n
\n\n\n\n\n\n\n\n\n\n
Test condition<\/span><\/th>\n Configuration<\/span><\/th>\n<\/tr>\n<\/thead>\n
Processor<\/span><\/td>\n Intel Core i7-12700; 12 cores, 20 logical processors<\/span><\/td>\n<\/tr>\n
Operating system and memory<\/span><\/td>\n Windows 11 Pro, build 26300; approximately 127.7 GiB of system-visible memory<\/span><\/td>\n<\/tr>\n
Runtime settings<\/span><\/td>\n Balanced power plan; no processor-affinity changes; background applications left running<\/span><\/td>\n<\/tr>\n
External reference<\/span><\/td>\n Apache Tika 3.3.0; Java 18.0.2 with a 1 GiB maximum heap; direct parser API calls, without starting an HTTP service<\/span><\/td>\n<\/tr>\n
Measurement scope<\/span><\/td>\n A fresh process per document; includes startup, initialization, text extraction, result output, and exit; excludes subsequent validation and scheduling by the test controller<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n
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.<\/p>\n
Each document\u2013implementation 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<\/strong>, plus 36 warm-ups excluded from the statistics. No slow measured executions were discarded.<\/p>\n
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<\/strong>; 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.<\/p>\n
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.<\/p>\n
The curves show the median and minimum\u2013maximum 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 \u201c1 \u2212 refactored value \u00f7 reference value.\u201d Reductions in different metrics cannot be added or combined into an overall performance-improvement percentage.<\/p>\n
Scope of the results<\/strong><\/h4>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"
Document text extraction is a foundational capability f […]<\/p>\n","protected":false},"author":1,"featured_media":1170,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1508","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-default"],"_links":{"self":[{"href":"https:\/\/www.nsecsoft.com\/en\/wp-json\/wp\/v2\/posts\/1508","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.nsecsoft.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.nsecsoft.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.nsecsoft.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.nsecsoft.com\/en\/wp-json\/wp\/v2\/comments?post=1508"}],"version-history":[{"count":2,"href":"https:\/\/www.nsecsoft.com\/en\/wp-json\/wp\/v2\/posts\/1508\/revisions"}],"predecessor-version":[{"id":1510,"href":"https:\/\/www.nsecsoft.com\/en\/wp-json\/wp\/v2\/posts\/1508\/revisions\/1510"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.nsecsoft.com\/en\/wp-json\/wp\/v2\/media\/1170"}],"wp:attachment":[{"href":"https:\/\/www.nsecsoft.com\/en\/wp-json\/wp\/v2\/media?parent=1508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.nsecsoft.com\/en\/wp-json\/wp\/v2\/categories?post=1508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.nsecsoft.com\/en\/wp-json\/wp\/v2\/tags?post=1508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}