Performance Comparison in C, Python, Erlang, and Haskell: Why the Same Algorithm Runs at Different Speeds

By the end of this page, you will understand why the same algorithm can have very different runtimes across languages, even when the code looks similar. You will learn how runtime systems, integer representations, recursion style, compiler optimizations, laziness, and interpreter overhead affect performance in C, Python, Erlang, and Haskell. You will also see practical ways to optimize code while keeping the underlying algorithm mostly the same.

The core concept here is performance depends on both the algorithm and the language runtime model.

Many beginners expect that if two programs do the same work, they should run at roughly the same speed. In practice, that is not true. Runtime performance is influenced by several layers:

• Algorithmic cost: how much work the program does
• Data representation: machine integers vs boxed integers vs arbitrary-precision integers
• Execution model: compiled native code, bytecode, VM, interpreter, JIT
• Language semantics: strict evaluation vs lazy evaluation
• Function-call overhead: loops, recursion, closures, guards, pattern matching
• Library and runtime startup costs

In your example, all versions are using roughly the same high-level algorithm:

1. Generate triangle numbers
2. Count divisors of each triangle number
3. Stop when divisor count exceeds 1000

That means the main algorithm is held mostly constant, so differences in execution time mainly reflect language implementation details and how naturally the code maps to efficient execution in that language.

Integer representation matters

Some languages use different integer strategies:

• C: usually fixed-size machine integers like long
• Python: integers are objects; even small integers have object overhead
• Erlang: supports small integers efficiently, but values are still managed by the VM
• Haskell: depends on the type; Int is fixed-size, Integer is arbitrary precision

Think of the algorithm as a recipe and the programming language as the kitchen.

All four cooks are making the same dish:

• C works in a professional kitchen with sharp tools and little safety overhead.
• Python works in a very flexible kitchen where every tool is labeled, checked, and easy to use, but slower.
• PyPy is like Python with a smart assistant who notices repeated work and speeds it up.
• Erlang works in a kitchen designed for many cooks collaborating safely, not for one cook chopping vegetables as fast as possible.
• Haskell works in a kitchen where ingredients may be prepared lazily and with elegant abstractions, but if you do not guide it well, extra work can build up.

So even if the recipe is the same, the kitchens behave differently. The language runtime, compiler, and data model all affect speed.

Core idea: same task, different execution models

Here is a small divisor-counting example in Python:

import math


def factor_count(n):
    root = int(math.sqrt(n))
    count = 0

    for candidate in range(1, root + 1):
        if n % candidate == 0:
            count += 2

    if root * root == n:
        count -= 1

    return count


print(factor_count(28))  # 6

Why 28 has 6 divisors

The divisors are:

• 1
• 2
• 4
• 7
• 14
• 28

The loop only checks up to sqrt(28), because divisors come in pairs:

• 1 × 28
• 2 × 14
• 4 × 7

This is much faster than checking every number up to .

Trace example

Let us trace a small version with n = 16.

Python example:

import math


def factor_count(n):
    root = int(math.sqrt(n))
    count = 0

    for candidate in range(1, root + 1):
        if n % candidate == 0:
            count += 2

    if root * root == n:
        count -= 1

    return count


print(factor_count(16))

Step by step

1. n = 16
2. math.sqrt(16) is 4.0
3. root = 4
4. count = 0

Now the loop runs from 1 to 4:

This exact Project Euler task is artificial, but the underlying ideas appear in real software.

1. CPU-bound batch processing

If your program spends most of its time doing arithmetic and loops, language runtime overhead becomes visible.

Examples:

• data analysis scripts
• simulation code
• puzzle solving
• computational search

2. Benchmarking implementations

Teams often prototype in one language and later rewrite hot paths.

Examples:

• Python app with a C extension
• Python code accelerated by PyPy, NumPy, or Rust
• Haskell code tuned with strictness annotations

3. Choosing the right integer type

Many applications do not need arbitrary-precision integers.

Examples:

• counters
• IDs
• indexes
• small numeric calculations

Using bigger numeric abstractions than necessary can cost performance.

4. Understanding runtime trade-offs

Some languages prioritize:

• raw speed
• safety
• concurrency
• expressiveness
• productivity

Erlang, for example, is often chosen for reliability and concurrency, not tight arithmetic loops.

5. Fair performance testing

A fair benchmark should control for:

• optimization flags
• warm-up time for JITs
• equivalent data types
• input size
• startup cost vs steady-state runtime

In real codebases, developers rarely stop at “same algorithm, same syntax.” They also adapt the code to the language.

Common patterns developers use

Guard clauses and early exits

Instead of doing extra work, return as soon as a condition is met.

if n < 1:
    return 0

Fixed-size integers when possible

In Haskell, choosing Int instead of Integer can matter a lot if overflow is not a concern.

factorCount :: Int -> Int

Compiler optimization flags

For Haskell, ghc -O2 is a common baseline for performance-sensitive code.

For C, -O2 or -O3 is also common.

Avoid unnecessary conversions

Repeated conversions between integer and floating-point types can slow code and create extra work.

Tail-recursive loops in functional languages

Erlang and Haskell code often uses recursive helper functions that accumulate results.

Keep hot paths simple

In performance-critical code, developers reduce:

1. Assuming arbitrary-precision integers are the only reason for slowness

That is only part of the story.

Even when numbers fit into machine range, these still matter:

• boxed objects
• VM overhead
• interpreter dispatch
• laziness
• missing optimization flags

2. Comparing unoptimized builds

A very common mistake is benchmarking debug or default builds.

Better approach

• C: compile with -O2 or -O3
• Haskell: compile with -O2
• PyPy: allow warm-up for JIT-heavy loops

Broken comparison idea:

gcc program.c -o app
./app

Better:

gcc -O2 program.c -lm -o app
./app

3. Ignoring Haskell numeric types

If no type is written, Haskell may infer a more general or more expensive numeric type than you expect.

Potentially problematic style:

factorCount number = ...

Safer for performance-sensitive code:

factorCount :: Int -> Int
factorCount number = ...

4. Forgetting that startup time affects short programs

Comparing the main causes of slowdown

Quick answers

• Same algorithm does not mean same speed.
• C is fast here because of native code and cheap machine integers.
• Python is slower mainly because integers are objects and loops run through the interpreter.
• PyPy can greatly improve Python loop performance with JIT compilation.
• Erlang is optimized for concurrency and fault tolerance, not numeric inner loops.
• Haskell performance depends heavily on types, strictness, and compiler flags.

Integer rules

• C long: fixed-size, fast
• Python int: arbitrary precision, object overhead
• Erlang integer: VM-managed, supports big integers
• Haskell Int: fixed-size, faster
• Haskell Integer: arbitrary precision, slower

Haskell performance tips

ghc -O2 file.hs -o app

Prefer explicit types:

factorCount :: Int -> Int

Be careful with laziness in accumulators.

Safer perfect-square check

Instead of comparing float equality directly:

root = int(math.sqrt(n))
 root * root == n:
    count -= 

Why is C usually faster than Python for numeric loops?

C compiles directly to native machine code and uses cheap primitive values. Python executes through an interpreter and uses objects for integers, which adds overhead.

Does Python always use arbitrary-precision integers?

Yes, Python integers are arbitrary precision. Even small integers still behave as Python objects, so there is overhead before values become “big.”

Does Haskell always use arbitrary-precision integers?

No. Int is fixed-size and usually faster. Integer is arbitrary precision and slower but avoids overflow.

Why can PyPy be much faster than CPython?

PyPy uses a JIT compiler, which can optimize repeated pure-Python operations at runtime, especially loops and arithmetic-heavy code.

Is tail recursion enough to make Haskell fast?

Not always. Tail recursion helps, but laziness can still build deferred computations unless values are evaluated strictly.

Is Erlang a bad language for math-heavy programs?

Not bad, but it is not usually the first choice for tight CPU-bound arithmetic loops. Its strengths are concurrency, distribution, and fault tolerance.

How can I make a fair language benchmark?

Use optimized builds, equivalent numeric types, realistic inputs, and idiomatic implementations for each language. Also separate startup time from actual computation time.

Should I optimize the language choice or the algorithm first?

Usually the algorithm first. A better algorithm often gives much larger gains than switching languages.

• Algorithmic complexity — performance depends first on how much work the algorithm does.
• Big-O notation — useful for understanding why some optimizations matter more than micro-tuning.
• Tail recursion — directly related to stack usage and recursion performance.
• Lazy evaluation — important for understanding Haskell performance behavior.
• Compiler optimization flags — flags like -O2 can dramatically change runtime speed.
• Boxing and unboxing — explains why primitive values can be faster than heap-allocated objects.
• JIT compilation — helps explain why PyPy can approach or beat compiled code in some loops.
• Fixed-size vs arbitrary-precision integers — central to numeric performance comparisons.
• Benchmarking — teaches how to measure performance fairly and meaningfully.
• Profiling — helps find real bottlenecks before optimizing.