CODE, ARCHITECTURE AND RUNTIME CHANGES

Lab

Queued orders, heavy reports, slow queries. Increase the workload and compare how the original implementation and improved code complete the same task.

Read our measurement principles

Choose a problem in your workflow

Orders queue at peak timesJava 8 → 25Reports keep the team waitingPHP 8.4Queries slow down as data growsSQLite 3.46The invoice list freezesWeb arayüzü / Web UIProduct imports take too long.NET 10Month-end reports take too longSQLite 3.46

Java 8 → 25 LAB MEASUREMENT

One order, three services. Stop stacking the waits.

Prepare an order using price, stock and shipping responses. We measured runtime migration and concurrent workflow changes separately against identical order results.

Business effect

Clear a peak-time order queue sooner. Run independent tasks together rather than occupying a worker while each service responds.

BEFOREJava 8 · sequential calls

MODERNIZEDJava 25 · virtual threads

Orders submitted together256

16Recorded loads only256

Actual time scale

SAME TASK · SAME DATA10 runs · median

Java 8 · sequential calls

8 workers; wait for three independent services sequentially per order.

2.95 s

CPU time: 259.207 ms
Peak platform threads: 12

Java 25 · unchanged old code

Same bytecode and same 8 workers. Only the runtime changed.

2.93 s

CPU time: 256.989 ms
Peak platform threads: 14

Java 25 · parallel platform control

Parallel calls; 64 platform workers and a 64-call dependency limit.

399.298 ms

CPU time: 108.114 ms
Peak platform threads: 70

Java 25 · virtual threads

Parallel independent calls; same 64-call limit, one virtual thread per task.

380.91 ms

CPU time: 125.21 ms
Peak platform threads: 18

Bars start at zero and share the same time scale across implementations.

Completion time reduced87.1%Time difference: 2.569 sOriginal → modernized implementation

What changed?

Split independent service calls and start them together. Java 25 virtual threads carry waiting tasks on fewer platform threads. The matched platform-pool control shows similar speed with a different thread footprint.

All load points and measurements

16 · Orders submitted together
Implementation	Median duration	CPU time	Peak platform threads
Java 8 · sequential calls	182.873 ms	25.94 ms	12
Java 25 · unchanged old code	184.777 ms	18.021 ms	14
Java 25 · parallel platform control	31.538 ms	11.909 ms	70
Java 25 · virtual threads	31.61 ms	10.142 ms	18

64 · Orders submitted together
Implementation	Median duration	CPU time	Peak platform threads
Java 8 · sequential calls	729.54 ms	52.624 ms	12
Java 25 · unchanged old code	725.443 ms	65.806 ms	14
Java 25 · parallel platform control	97.516 ms	29.633 ms	70
Java 25 · virtual threads	97.451 ms	42.585 ms	18

256 · Orders submitted together
Implementation	Median duration	CPU time	Peak platform threads
Java 8 · sequential calls	2.95 s	259.207 ms	12
Java 25 · unchanged old code	2.93 s	256.989 ms	14
Java 25 · parallel platform control	399.298 ms	108.114 ms	70
Java 25 · virtual threads	380.91 ms	125.21 ms	18

CPU cost at your workload

Compare the recorded CPU time at your own monthly volume.

One batch run = 256 Orders submitted together.

Monthly batch runs · model inputCPU-hour price · TRY

CPU time reduced / month0.3722 hours

Processing cost difference / month—Calculated after you enter a unit price.

Lab CPU time × your volume and unit price. This is not a hosting bill forecast; idle capacity, networking, storage, licences and migration are excluded.

Java 8 → 25 LAB MEASUREMENT

One order, three services. Stop stacking the waits.

Prepare an order using price, stock and shipping responses. We measured runtime migration and concurrent workflow changes separately against identical order results.

Business effect

Clear a peak-time order queue sooner. Run independent tasks together rather than occupying a worker while each service responds.

BEFOREJava 8 · sequential calls

MODERNIZEDJava 25 · virtual threads

Orders submitted together256

16Recorded loads only256

SAME TASK · SAME DATA10 runs · median

Java 8 · sequential calls

8 workers; wait for three independent services sequentially per order.

2.95 s

CPU time: 259.207 ms
Peak platform threads: 12

Java 25 · unchanged old code

Same bytecode and same 8 workers. Only the runtime changed.

2.93 s

CPU time: 256.989 ms
Peak platform threads: 14

Java 25 · parallel platform control

Parallel calls; 64 platform workers and a 64-call dependency limit.

399.298 ms

CPU time: 108.114 ms
Peak platform threads: 70

Java 25 · virtual threads

Parallel independent calls; same 64-call limit, one virtual thread per task.

380.91 ms

CPU time: 125.21 ms
Peak platform threads: 18

Bars start at zero and share the same time scale across implementations.

Completion time reduced87.1%Time difference: 2.569 sOriginal → modernized implementation

What changed?

All load points and measurements

16 · Orders submitted together
Implementation	Median duration	CPU time	Peak platform threads
Java 8 · sequential calls	182.873 ms	25.94 ms	12
Java 25 · unchanged old code	184.777 ms	18.021 ms	14
Java 25 · parallel platform control	31.538 ms	11.909 ms	70
Java 25 · virtual threads	31.61 ms	10.142 ms	18

64 · Orders submitted together
Implementation	Median duration	CPU time	Peak platform threads
Java 8 · sequential calls	729.54 ms	52.624 ms	12
Java 25 · unchanged old code	725.443 ms	65.806 ms	14
Java 25 · parallel platform control	97.516 ms	29.633 ms	70
Java 25 · virtual threads	97.451 ms	42.585 ms	18

256 · Orders submitted together
Implementation	Median duration	CPU time	Peak platform threads
Java 8 · sequential calls	2.95 s	259.207 ms	12
Java 25 · unchanged old code	2.93 s	256.989 ms	14
Java 25 · parallel platform control	399.298 ms	108.114 ms	70
Java 25 · virtual threads	380.91 ms	125.21 ms	18

PHP 8.4 LAB MEASUREMENT

Stop reading the same orders again and again.

Order totals by customer. Same PHP version, same data, same output; a different way to compute it.

Business effect

Repeated reports consume less CPU. The task spends less time running while the team waits for its result.

BEFORERescan for every customer

MODERNIZEDAggregate in one pass

Order records200,000

1,000Recorded loads only200,000

SAME TASK · SAME DATA10 runs · median

Rescan for every customer

Read the order list again for each customer.

1.265 s

CPU time: 1.265 s

Aggregate in one pass

Read orders once and accumulate totals by customer key.

8.487 ms

CPU time: 8.495 ms

Bars start at zero and share the same time scale across implementations.

Completion time reduced99.3%Time difference: 1.257 sOriginal → modernized implementation

What changed?

Replace a full scan per customer with totals indexed by customer key. Business rules and integer-cent amounts remain identical.

All load points and measurements

1,000 · Order records
Implementation	Median duration	CPU time
Rescan for every customer	2.93 ms	2.916 ms
Aggregate in one pass	0.04 ms	0.041 ms

3,000 · Order records
Implementation	Median duration	CPU time
Rescan for every customer	8.362 ms	8.363 ms
Aggregate in one pass	0.114 ms	0.114 ms

10,000 · Order records
Implementation	Median duration	CPU time
Rescan for every customer	28.426 ms	28.429 ms
Aggregate in one pass	0.371 ms	0.373 ms

30,000 · Order records
Implementation	Median duration	CPU time
Rescan for every customer	83.354 ms	83.352 ms
Aggregate in one pass	0.898 ms	0.902 ms

60,000 · Order records
Implementation	Median duration	CPU time
Rescan for every customer	190.504 ms	190.479 ms
Aggregate in one pass	2.059 ms	2.065 ms

100,000 · Order records
Implementation	Median duration	CPU time
Rescan for every customer	436.716 ms	436.251 ms
Aggregate in one pass	4.175 ms	4.183 ms

200,000 · Order records
Implementation	Median duration	CPU time
Rescan for every customer	1.265 s	1.265 s
Aggregate in one pass	8.487 ms	8.495 ms

Fix the query and tenant access together.

Normal order
Before
Passed
✓ After
Passed
Missing order
Before
Passed
✓ After
Passed
Apostrophe in order reference
Before
Query error
✓ After
Passed
SQL input bypass
Before
6 unauthorized rows
✓ After
Passed
SQL input targeting another tenant
Before
6 unauthorized rows
✓ After
Passed
Direct cross-tenant reference
Before
1 unauthorized rows
✓ After
Passed

Security test and evidence ↗

SQLite 3.46 LAB MEASUREMENT

Find the rows you need without scanning the whole table.

Open order totals by customer. The same query before and after indexing, on the same SQLite engine.

Business effect

Reports and list screens do less CPU work. Fixing the query plan can reduce the need to scale hardware.

BEFOREUnindexed query

MODERNIZEDSame query + composite index

Order records200,000

1,000Recorded loads only200,000

SAME TASK · SAME DATA10 runs · median

Unindexed query

Scan the orders table for each customer total.

1.129 s

CPU time: 1.129 s

Same query + composite index

Use a covering index on customer, status and amount.

7.188 ms

CPU time: 7.187 ms

Index + grouped-query control

An alternative grouped query was also measured for the same output.

10.158 ms

CPU time: 10.16 ms

Bars start at zero and share the same time scale across implementations.

Completion time reduced99.4%Time difference: 1.122 sOriginal → modernized implementation

What changed?

Add a composite covering index for the customer and status filters. Keep the grouped-query alternative as a separate control.

All load points and measurements

1,000 · Order records
Implementation	Median duration	CPU time
Unindexed query	5.995 ms	5.996 ms
Same query + composite index	0.146 ms	0.147 ms
Index + grouped-query control	0.213 ms	0.215 ms

3,000 · Order records
Implementation	Median duration	CPU time
Unindexed query	16.785 ms	16.786 ms
Same query + composite index	0.227 ms	0.228 ms
Index + grouped-query control	0.292 ms	0.293 ms

10,000 · Order records
Implementation	Median duration	CPU time
Unindexed query	55.749 ms	55.743 ms
Same query + composite index	0.536 ms	0.538 ms
Index + grouped-query control	0.694 ms	0.695 ms

30,000 · Order records
Implementation	Median duration	CPU time
Unindexed query	175.175 ms	175.158 ms
Same query + composite index	1.23 ms	1.231 ms
Index + grouped-query control	1.695 ms	1.696 ms

60,000 · Order records
Implementation	Median duration	CPU time
Unindexed query	345.649 ms	345.617 ms
Same query + composite index	2.292 ms	2.298 ms
Index + grouped-query control	3.264 ms	3.265 ms

100,000 · Order records
Implementation	Median duration	CPU time
Unindexed query	565.92 ms	565.9 ms
Same query + composite index	3.691 ms	3.693 ms
Index + grouped-query control	5.213 ms	5.214 ms

200,000 · Order records
Implementation	Median duration	CPU time
Unindexed query	1.129 s	1.129 s
Same query + composite index	7.188 ms	7.187 ms
Index + grouped-query control	10.158 ms	10.16 ms

Web arayüzü / Web UI LAB MEASUREMENT

50,000 invoices. Render the rows the screen needs.

Filter overdue invoices. Identical records and scrollable range; a different number of rows rendered at once.

Business effect

The finance team spends less time waiting for a large list to respond. Keep the complete result set and render the visible section.

BEFORERender every matching row

MODERNIZEDRender the visible window

Source invoice records50,000

1,000Recorded loads only50,000

SAME TASK · SAME DATA10 runs · median

Render every matching row

A separate DOM row for every match.

1.386 s

Invoice rows in the DOM: 33,333

Render the visible window

Complete result list; a 40-row viewport window.

16.5 ms

Invoice rows in the DOM: 40

Bars start at zero and share the same time scale across implementations.

Completion time reduced98.8%Time difference: 1.369 sOriginal → modernized implementation

What changed?

Replace one DOM row per match with a 40-row viewport window. The same filter still examines every record; scrolling updates the window.

All load points and measurements

1,000 · Source invoice records
Implementation	Median duration	Invoice rows in the DOM
Render every matching row	29.4 ms	666
Render the visible window	16.6 ms	40

10,000 · Source invoice records
Implementation	Median duration	Invoice rows in the DOM
Render every matching row	244.9 ms	6,666
Render the visible window	16.55 ms	40

50,000 · Source invoice records
Implementation	Median duration	Invoice rows in the DOM
Render every matching row	1.386 s	33,333
Render the visible window	16.5 ms	40

Customer names stay text.

Customer 42
Before
Text preserved
✓ After
Text preserved; no HTML element created
A & B
Before
Text preserved
✓ After
Text preserved; no HTML element created
North < East > West
Before
Text preserved
✓ After
Text preserved; no HTML element created
Quote " and apostrophe '
Before
Text preserved
✓ After
Text preserved; no HTML element created
<b data-probe>Customer 42</b>
Before
HTML element created
✓ After
Text preserved; no HTML element created
<span title="synthetic">Invoice</span>
Before
HTML element created
✓ After
Text preserved; no HTML element created

Security test and evidence ↗

.NET 10 LAB MEASUREMENT

Stop searching the full catalog for every row.

Match product codes in an order import against a 10,000-product catalog. Same .NET version and output; keyed access instead of repeated list scans.

Business effect

Reduce waiting and repeated CPU work in large product and order imports. Each incoming row no longer triggers another search through the entire catalog.

BEFOREScan the list for every row

MODERNIZEDDictionary lookup by product code

Imported file rows50,000

1,000Recorded loads only50,000

SAME TASK · SAME DATA10 runs · median

Scan the list for every row

List.Find with a capturing predicate per row. Identical catalog ordering and business rule.

708.219 ms

CPU time: 705.682 ms
Managed allocation (bytes): 4,801,064

Dictionary lookup by product code

Includes index construction and the output array. Dictionary is also available in older .NET versions.

1.506 ms

CPU time: 1.528 ms
Managed allocation (bytes): 684,080

FrozenDictionary control

Modern read-only API with construction included. It is not assumed to be faster for every file.

1.961 ms

CPU time: 1.991 ms
Managed allocation (bytes): 1,610,160

Bars start at zero and share the same time scale across implementations.

Completion time reduced99.8%Time difference: 706.713 msOriginal → modernized implementation

What changed?

Replace repeated List.Find searches with a Dictionary keyed by product code. Rebuild the index for every file and include that construction time in the total. Measure FrozenDictionary as an additional alternative.

All load points and measurements

1,000 · Imported file rows
Implementation	Median duration	CPU time	Managed allocation (bytes)
Scan the list for every row	14.216 ms	14.237 ms	97,064
Dictionary lookup by product code	0.21 ms	0.229 ms	292,080
FrozenDictionary control	0.897 ms	0.915 ms	1,218,160

10,000 · Imported file rows
Implementation	Median duration	CPU time	Managed allocation (bytes)
Scan the list for every row	143.355 ms	142.927 ms	961,064
Dictionary lookup by product code	0.466 ms	0.488 ms	364,080
FrozenDictionary control	1.059 ms	1.076 ms	1,290,160

50,000 · Imported file rows
Implementation	Median duration	CPU time	Managed allocation (bytes)
Scan the list for every row	708.219 ms	705.682 ms	4,801,064
Dictionary lookup by product code	1.506 ms	1.528 ms	684,080
FrozenDictionary control	1.961 ms	1.991 ms	1,610,160

SQLite 3.46 LAB MEASUREMENT

500 customer balances from 5 million orders.

Run the same open-order balance report. Business rules and engine stay the same; the access path that scans the whole table per customer changes.

Business effect

Repeated month-end checks take less time and CPU work. The team can move from waiting for a report to reviewing its balances.

BEFOREUnindexed month-end report

MODERNIZEDSame report + covering index

Order records5,000,000

100,000Recorded loads only5,000,000

SAME TASK · SAME DATA10 runs · median

Unindexed month-end report

Scan the entire order table again for each customer balance.

1 m 13.11 s

CPU time: 1 m 13.1 s

Same report + covering index

The same SQL finds amounts using customer and status keys.

175.502 ms

CPU time: 175.473 ms

Index + grouped-query control

An alternative that groups orders once; every result is retained, faster or slower.

254.653 ms

CPU time: 254.617 ms

Bars start at zero and share the same time scale across implementations.

Completion time reduced99.8%Time difference: 1 m 12.93 sOriginal → modernized implementation

What changed?

Add a composite index covering customer, order status and amount. SQL text is identical before and after. Measure a grouped-query alternative as a separate control.

All load points and measurements

100,000 · Order records
Implementation	Median duration	CPU time
Unindexed month-end report	1.435 s	1.435 s
Same report + covering index	3.833 ms	3.835 ms
Index + grouped-query control	5.507 ms	5.509 ms

1,000,000 · Order records
Implementation	Median duration	CPU time
Unindexed month-end report	14.751 s	14.749 s
Same report + covering index	36.498 ms	36.504 ms
Index + grouped-query control	52.952 ms	52.941 ms

5,000,000 · Order records
Implementation	Median duration	CPU time
Unindexed month-end report	1 m 13.11 s	1 m 13.1 s
Same report + covering index	175.502 ms	175.473 ms
Index + grouped-query control	254.653 ms	254.617 ms

7 cases shown

Lab caseOct 15, 2026
Before
After
Application modernization
Java 8 → 25: parallelizing an order integration
256 orders completed: 2.95 s → 380.91 ms. Synthetic lab; median of 10 runs. Open code and raw data.
Java 8 · sequential calls→Java 25 · virtual threads
JavaSMBEnterprisePartner
256 orders completed
Before
2,949.73 ms
After
380.91 ms
↓ 87.09%
Lower is better · Median of 10 runs
Measurement method
Explore the case
Lab caseOct 15, 2026
Before
After
Application modernization
Database optimization: queries and indexes
200,000 orders summarized: 1.13 s → 7.19 ms. Synthetic lab; median of 10 runs. Open code and raw data.
Unindexed query→Same query + composite index
DatabaseSMBEnterprisePartner
200,000 orders summarized
Before
1,129.16 ms
After
7.19 ms
↓ 99.36%
Lower is better · Median of 10 runs
Measurement method
Explore the case
Lab caseOct 15, 2026
Before
After
Application modernization
.NET bulk import: faster catalog lookups
50,000 catalog import rows: 708.22 ms → 1.51 ms. Synthetic lab; median of 10 runs. Open code and raw data.
Scan the list for every row→Dictionary lookup by product code
.NETSMBEnterprisePartner
50,000 catalog import rows
Before
708.22 ms
After
1.51 ms
↓ 99.79%
Lower is better · Median of 10 runs
Measurement method
Explore the case
Lab caseOct 15, 2026
Before
After
Application modernization
Frontend optimization: a 50,000-invoice list
50,000 invoices filtered and listed: 1.39 s → 16.5 ms. Synthetic lab; median of 10 runs. Open code and raw data.
Render every matching row→Render the visible window
FrontendSMBEnterprisePartner
50,000 invoices filtered and listed
Before
1,385.8 ms
After
16.5 ms
↓ 98.81%
Lower is better · Median of 10 runs
Measurement method
Explore the case
Lab caseOct 15, 2026
Before
After
Application modernization
Month-end reports across five million records
5,000,000 orders summarized: 1.22 min → 175.5 ms. Synthetic lab; median of 10 runs. Open code and raw data.
Unindexed month-end report→Same report + covering index
DatabaseSMBEnterprisePartner
5,000,000 orders summarized
Before
73,106.21 ms
After
175.5 ms
↓ 99.76%
Lower is better · Median of 10 runs
Measurement method
Explore the case
Lab caseOct 15, 2026
Before
After
Application modernization
PHP report optimization: one-pass aggregation
200,000 orders summarized: 1.27 s → 8.49 ms. Synthetic lab; median of 10 runs. Open code and raw data.
Rescan for every customer→Aggregate in one pass
PHPDatabaseSMBEnterprisePartner
200,000 orders summarized
Before
1,265.12 ms
After
8.49 ms
↓ 99.33%
Lower is better · Median of 10 runs
Measurement method
Explore the case
Lab caseOct 14, 2026
Before
After
Application modernization
Java 8 → 25: one order report, two runtimes
The same bytecode reports over 1 million in-memory orders in 1.891 ms → 1.886 ms. A synthetic runtime study across seven data sizes and 440 real JVM runs.
Corretto 8u432→Corretto 25.0.3
JavaSMBEnterprisePartner
In-memory report over 1 million orders
Before
1.89 ms
After
1.89 ms
↓ 0.3%
Lower is better · Median of 10 runs
Measurement method
Explore the case