2.2.2(a), 2.2.2(b), 2.2.2(c), 2.2.2(d), 2.2.2(e), 2.2.2(f)Problem Solving and ProgrammingCore

Computational Solutions and Performance Models

A computational solution needs representable inputs, defined rules and an assessable output. Model the difficult parts early, while keeping the difference between a prediction and measured behaviour visible.

35 min Computational Methods

What you'll be able to do

Explain features that make a problem amenable to computation
Apply decomposition, divide and conquer, pipelining and visualisation
Use a simple capacity model and state its limits

Turn a scenario into a defined task

Computers can apply precise rules repeatedly, store and search records, perform calculations and explore structured alternatives. A task becomes amenable to computation when relevant information can be represented and success can be assessed. Human judgement may still be required to choose goals, interpret ambiguous cases or resolve values not captured in the data.

Problem recognition identifies what must change or be found. Decomposition separates responsibilities; abstraction selects relevant information. Divide and conquer splits a suitable problem into smaller instances, solves them and combines their results, as in merge sort. Not every division of a project into files is a divide-and-conquer algorithm, and not every problem has a practical exact solution at the required scale.

Model processing stages and capacity

Performance modelling predicts behaviour from simplified assumptions before or alongside measurement. If one worker needs 0.02 seconds per request continuously, its ideal capacity is 50 requests per second. At 60 arrivals per second, the queue grows by about ten requests per second under this steady simplified model. Two independent workers could raise compute capacity, but a shared bottleneck may limit the gain.

Pipelining overlaps different stages for different items. With independent stages taking 1,3 and 2 milliseconds, the first item takes 6 ms and the slowest stage limits sustained completions to one every 3 ms. Ten items ideally take 6+9×3=33 ms, compared with 60 ms without overlap. This assumes sufficient buffers, no additional stalls and constant stage times.

Use visualisation to inspect assumptions

A timeline makes dependencies and idle periods visible; a graph shows connections; a state table reveals changing values. Visualisation can support a mental model of what the program will do and can expose a bottleneck or missing transition before implementation. The representation must use labels and scales that preserve the relevant meaning.

Validate predictions with representative measurements and revise assumptions when evidence differs. Real arrivals can be bursty, stage times vary, resources fail and synchronisation adds overhead. A model that predicts average capacity does not guarantee every request meets a deadline. Explain what the model includes, what it omits and which evidence would justify relying on it for the decision.

Model	Assumptions	Prediction
Single worker	0.02 s/request, steady 60 arrivals/s	50 served/s; backlog grows about 10/s
Three-stage pipeline	1,3,2 ms; independent resources and buffers	First item 6 ms; next completions every 3 ms
Ten-item batch	Same no-stall pipeline	33 ms ideal total

Scroll horizontally to see the full code or table.

Original simplified models; predictions need workload validation.

Work through the problem

Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.

Example 1A worker can serve 50 requests/s while 60 arrive/s. How much backlog is added in five seconds in the simplified model?

1Net growth is 60−50=10 requests/s.

2Over five seconds, 10×5=50 requests are added to the queue.

Answer50 requests, assuming the model’s constant rates and sufficient buffering.

Example 2Why does making the 1 ms pipeline stage twice as fast not double total throughput?

1The 3 ms stage is still the slowest stage.

2It continues to limit sustained completions even though the first stage is faster.

AnswerOptimise the actual bottleneck and re-evaluate the complete pipeline.

Common mistakes to avoid

Calling an assumption-based prediction a measurement.

State assumptions and compare with observed behaviour.

Optimising a stage without finding the bottleneck.

Analyse end-to-end dependencies and resource limits.

Key takeaways

Computational methods need clear representations and goals.
Models and visualisations support early reasoning.
Predictions require validation against representative workloads.

Test yourself

Answer a few questions, then review anything you missed.

Next step

Keep practising

Start with the quiz above to check the key ideas. You can also choose another topic from the practice library.

Browse practice topics

Related lessons

All 3 lessons

Model

Assumptions

Prediction

Single worker

0.02 s/request, steady 60 arrivals/s

50 served/s; backlog grows about 10/s

Three-stage pipeline

1,3,2 ms; independent resources and buffers

First item 6 ms; next completions every 3 ms

Ten-item batch

Same no-stall pipeline

33 ms ideal total