Software Waste Measurement: What Developers Can Monitor

Software may use more memory, CPU, storage, and network traffic than a feature requires. Although an imminent failure might not result from this increased resource utilization, it can lower application efficiency and raise infrastructure expenses.

Determining what “wasted compute” truly implies is the challenging part.

A CPU-intensive procedure is not always an issue, and a sluggish function is not always inefficient. Developers must assess how resources are being used in relation to the amount of productive work being produced.

What Is Wasted Compute?

Wasted compute is resource consumption that does not provide meaningful value to the application.

Consider this example:

Request
   |
   +-- Database Query
   |
   +-- Processing
   |
   +-- Duplicate Calculation
   |
   +-- Unused Serialization
   |
   v
Response

The duplicate calculation and unnecessary serialization may consume CPU without improving the final result.

Common examples include:

• Repeating the same database query
• Processing data that is never used
• Serializing unused fields
• Running background jobs with no useful output
• Recomputing values that could be cached
• Keeping idle resources active unnecessarily

CPU Is Only One Part of the Problem

When developers think about compute waste, CPU usage is usually the first metric they check.

A better view includes several resource types:

Resource	What to Track
CPU	Utilization and CPU time
Memory	Allocation, working set, and garbage collection
Database	Query time and execution count
Network	Bytes transferred
Storage	Read/write operations
GPU	Utilization and processing time
Application	Requests, jobs, and useful operations

A service using 70% CPU may be efficient if it is processing a large workload.

Another service using 20% CPU may be wasteful if it performs unnecessary work for every request.

Start With Useful Work

Resource usage becomes meaningful when compared with an application output.

For example:

CPU Time
   /
Successful Requests

This gives a rough measure of CPU consumed per successful request.

Similarly:

Database Queries
   /
Successful Requests

can reveal whether an application is performing unnecessary database work.

The goal is to measure resource consumption relative to useful output rather than looking at utilization alone.

Measure CPU Time

A basic performance investigation should identify which operations consume CPU.

In .NET, you can measure elapsed execution time with Stopwatch:

var stopwatch = Stopwatch.StartNew();

ProcessOrders();

stopwatch.Stop();

Console.WriteLine(
    $"Processing took {stopwatch.ElapsedMilliseconds} ms");

Elapsed time is useful, but it does not tell you how much CPU was actually consumed.

For deeper investigations, use a profiler or runtime diagnostics tool to identify expensive methods and call paths.

Measure Allocation in .NET

Memory allocations can create additional garbage-collection work.

For a small diagnostic measurement:

long before = GC.GetAllocatedBytesForCurrentThread();

ProcessOrders();

long after = GC.GetAllocatedBytesForCurrentThread();

Console.WriteLine(
    $"Allocated: {after - before} bytes");

This can help identify operations that allocate significantly more memory than expected.

It should be used for investigation rather than as a replacement for proper profiling.

Watch Garbage Collection

Frequent allocations can increase garbage-collection activity.

Useful metrics include:

Gen 0 collections
Gen 1 collections
Gen 2 collections
Allocated bytes
GC pause time

For example:

Request
   |
   v
Large Temporary Objects
   |
   v
More Allocations
   |
   v
More GC Work
   |
   v
Higher CPU Usage

Reducing unnecessary allocations can therefore improve both memory behavior and CPU efficiency.

Find Duplicate Database Work

Database activity is another common source of wasted resources.

Consider:

var customer = await GetCustomerAsync(id);

var orders = await GetOrdersAsync(id);

var customerAgain = await GetCustomerAsync(id);

If customerAgain does not provide new information, the second customer query may be unnecessary.

A better design could reuse the existing result:

var customer = await GetCustomerAsync(id);

var orders = await GetOrdersAsync(customer.Id);

The correct solution depends on application behavior, but query duplication should be visible during performance analysis.

Measure Query Frequency

A slow query is not the only database problem.

Suppose a query takes 5 milliseconds.

Running it once may be insignificant.

Running it 10,000 times during a single workload is a different problem.

Track both:

Query Duration
+
Query Count

A useful investigation looks for queries that are:

• Slow
• Frequently executed
• Repeated unnecessarily
• Returning more data than required

Avoid Processing Unused Data

Consider an API that retrieves 50 database columns when the application uses only three.

SELECT *
FROM customers;

This can increase:

• Database work
• Network transfer
• Object creation
• Serialization
• Deserialization

Instead, request the fields that are actually needed:

SELECT
    id,
    name,
    status
FROM customers;

This does not mean SELECT * is always wrong. It means data access should match the actual requirements of the operation.

Measure Background Jobs

Background services can consume resources even when users are not actively using the application.

For example:

Background Job
     |
     +-- Runs every minute
     |
     +-- Finds nothing to process
     |
     +-- Exits

If this happens continuously, the application may be spending resources repeatedly checking for work that rarely exists.

Useful metrics include:

Job executions
Successful jobs
Empty executions
Execution duration
CPU time
Items processed

If a job runs 1,440 times per day but performs useful work only a few times, the scheduling strategy may deserve review.

Measure Idle Infrastructure

Not all waste happens inside application code.

Infrastructure can also remain underused:

Application Server
CPU: 5%
Memory: 15%

That does not automatically mean the server should be removed. It may be required for traffic spikes, availability, or failover.

Infrastructure decisions should therefore consider:

• Average utilization
• Peak utilization
• Availability requirements
• Scaling behavior
• Traffic patterns
• Cost

Avoid reducing capacity simply because average utilization is low.

Track Compute Per Work Unit

One of the most useful metrics is resource usage per meaningful unit of work.

Examples include:

CPU milliseconds per request
Memory allocated per request
Database queries per request
Bytes transferred per request
CPU time per processed record

For a batch-processing application:

CPU Time / Records Processed

can be more useful than simply looking at total CPU usage.

Compare Before and After

Performance work becomes more useful when measurements can be compared.

For example:

Metric	Before	After
CPU per request	18 ms	11 ms
Allocations per request	85 KB	52 KB
DB queries per request	8	5
Response time	120 ms	92 ms

These numbers should come from actual measurements.

Do not treat a small change as meaningful without considering measurement noise, workload differences, and test conditions.

Use Profiling Before Optimizing

Developers should avoid optimizing based only on assumptions.

A better workflow is:

Observe
   |
   v
Measure
   |
   v
Find Expensive Operation
   |
   v
Change Code
   |
   v
Measure Again

Profilers can help identify:

• Expensive methods
• Allocation hotspots
• Lock contention
• Database delays
• CPU-heavy operations

The exact profiling tool depends on the language and runtime.

Common Sources of Wasted Compute

Repeated Work

The same calculation or query is performed multiple times.

Excessive Serialization

The application converts data into formats that are never consumed.

Over-Fetching

The database returns significantly more information than required.

Unnecessary Polling

A background service repeatedly checks for work when an event-driven approach could be used.

Excessive Logging

Large amounts of logging can consume CPU, storage, and network resources.

Inefficient Algorithms

An algorithm can become expensive as the input size increases.

For example, replacing an unnecessary O(n²) operation with an O(n) approach can have a significant effect as data grows.

Best Practices

1. Measure before changing code.
2. Track resource usage per meaningful unit of work.
3. Monitor CPU and memory together.
4. Track database query count as well as query duration.
5. Look for duplicate operations.
6. Avoid fetching data that the application does not need.
7. Measure background jobs separately.
8. Use profiling to find actual hotspots.
9. Compare measurements before and after optimization.
10. Consider peak workload rather than only average usage.

Advantages of Tracking Compute Waste

• Helps identify inefficient code.
• Can reduce unnecessary database activity.
• Makes performance investigations more objective.
• Helps developers understand infrastructure usage.
• Can improve application responsiveness.
• Provides useful data for capacity planning.

Limitations

Resource optimization also has trade-offs.

For example, caching can reduce CPU and database work but increase memory usage.

Similarly, compression can reduce network traffic but increase CPU usage.

A change should therefore be evaluated across the complete system:

CPU
 |
 +-- Memory
 |
 +-- Database
 |
 +-- Network
 |
 +-- Storage

Reducing one resource does not automatically make the entire application more efficient.

A Practical Measurement Workflow

A simple approach is:

1. Define Useful Work
       |
       v
2. Choose Metrics
       |
       v
3. Measure Current Behavior
       |
       v
4. Find Expensive Operations
       |
       v
5. Make One Change
       |
       v
6. Measure Again
       |
       v
7. Compare Results

For example, if an API consumes too much CPU, measure CPU time per request first. Then profile the request and identify the expensive operation.

Do not immediately rewrite the entire API.

Conclusion

Wasted compute is not simply high CPU usage. It is resource consumption that does not provide enough useful application work in return.

Developers can start by measuring:

CPU per request
Memory allocated per request
Database queries per request
Network bytes per request
Background work completed

These measurements provide more useful information than looking at a single CPU or memory percentage.

The most important habit is simple: measure first, optimize second, and measure again.

When developers track resource usage against meaningful application work, they can identify unnecessary computation without optimizing code that was never actually a problem.

Best ASP.NET Core 11.0 Hosting

The feature and reliability are the most important things when choosing a good ASP.NET Core 11.0 hosting. HostForLIFE is the leading provider of Windows hosting and affordable ASP.NET Core , their servers are optimized for PHP web applications such as the latest ASP.NET Core 11.0 version. The performance and the uptime of the ASP.NET Core  hosting service are excellent, and the features of the web hosting plan are even greater than what many hosting providers ask you to pay for. At HostForLIFE.eu, customers can also experience fast ASP.NET Core hosting. The company invested a lot of money to ensure the best and fastest performance of the datacenters, servers, network and other facilities. Its data centers are equipped with top equipment like cooling system, fire detection, high-speed Internet connection, and so on. That is why HostForLIFE.eu guarantees 99.9% uptime for ASP.NET Core . And the engineers do regular maintenance and monitoring works to assure its ASP.NET Core  hosting are security and always up.