Let's consider a hypothetical algorithm that has a complexity described by . Assume that there is an inner loop that involves 1,000 bytes of Python code. When processing 10,000 objects, we're executing 100 billion Python operations. We can call this the essential processing budget. We can try to allocate as many processes and threads as we feel might be helpful, but the processing budget can't change.

An individual CPython bytecode doesn't have simple execution timing. However, a long-term average on a macOS X laptop shows that we can expect about 60 MB of code to be executed per second. This means that our 100 billion bytecode operation will take about 1,666 seconds, or 28 minutes.

If we have a dual-processor, four-core computer, then we might cut the elapsed time to 25% of the original total: about 7 minutes. This presumes that we can partition the work into four (or more) independent OS processes.

The important consideration here is that the overall budget of 100 billion bytecodes can't be changed. Parallelism won't magically reduce the workload. It can only change the schedule to perhaps reduce the elapsed time.

Switching to a better algorithm, , can reduce the workload from 100 billion operations to 133 million operations with a potential runtime of about 2 seconds. Spread over four cores, we might see a response in 516 milliseconds. Parallelism can't have the kind of dramatic improvements that algorithm change will have.