A data-driven guide to selecting between python:slim, Intel Python, and Anaconda for hedge fund batch jobs

---

1. Executive Summary

Choosing the right Docker base image for Python data workloads can significantly impact both performance and operational costs. This benchmark suite tests three popular images—python:3.14-slim, intel/python, and continuumio/anaconda3—across finance-oriented workloads including IO operations, ETL pipelines, linear algebra, and CPU-bound Python code. The key finding: for most workloads, images perform within 10% of each other, making the smallest image (python:3.14-slim at ~150MB) the optimal default choice. The exception is dense linear algebra (matrix multiplication, SVD, eigenvalue decomposition), where Intel’s MKL-optimized image can deliver 1.1×–2.0× speedups—but only on Intel CPUs. On AMD processors, MKL’s vendor-detection code can actually make it slower than the standard OpenBLAS library. The recommendation engine follows a simple rule: prefer the smallest image unless benchmarks prove a larger specialized image delivers measurable gains on your specific hardware.

---

2. Real-World Use Case

We were running a critical end-of-day batch job on Intel Python—processing hundreds of millions of rows across our asset universe, computing risk metrics, and generating portfolio summaries. The code is multi-threaded to saturate all available CPUs, using ProcessPoolExecutor for the heavy lifting. The job consistently took 5 minutes. When we migrated to python:3.14-slim as a container optimization exercise, the same job completed in under 3 minutes. No code changes. No algorithm tweaks. Just a different base image.

The irony? We originally chose Intel Python for performance. But our workload was dominated by pandas DataFrames and Python loops for custom business logic—exactly where Python 3.14’s interpreter improvements shine. The MKL advantage only matters if you’re doing heavy linear algebra, which we weren’t.

The 40% runtime reduction isn’t just about compute costs—though those savings are real. It’s about decision velocity. When markets move, portfolio managers need updated risk numbers now, not in five minutes. Shaving two minutes off our batch window means traders get actionable intelligence faster, and that edge compounds across hundreds of decisions per day.

Smaller image, faster pulls, faster execution, faster decisions. Sometimes the ‘boring’ choice wins.

– Systematic Trading Hedge Fund

---

3. Decision Tree: Choosing Your Docker Image

Use this decision tree to quickly identify the optimal Docker image for your workload:

Step 1: What CPU Architecture Are You Using?

→ AMD Processors (Ryzen, EPYC, Threadripper)

• Recommendation: Always use python:3.14-slim
• Why: Intel MKL (used by intel/python and anaconda) contains CPU vendor detection that can throttle performance on AMD hardware. OpenBLAS (bundled with python:slim) is vendor-neutral and often faster than MKL on AMD.
• BLAS-heavy workloads: OpenBLAS performs well; no need for MKL
• All other workloads: python:3.14-slim provides best interpreter performance and smallest image size
• Action: Skip to Step 2 for threading guidance

→ Intel Processors (Xeon, Core i-series)

• Consider workload type before choosing
• BLAS-heavy workloads (matrix ops, SVD, eigenvalue, Cholesky):
• Use intel/python or anaconda for 10–100% speedups from MKL
• Verify with benchmarks on your specific hardware
• All other workloads: Use python:3.14-slim
• Performance within 10% of larger images
• 20× smaller image size (~150MB vs ~3GB)
• Latest interpreter optimizations
• Action: Proceed to Step 2 for threading guidance

---

Step 2: Single-Threaded or Multi-Threaded Workload?

→ Single-Threaded Workloads

Workload Type	Best Image	Best Approach
Pure Python loops	python:3.14-slim	Leverage 3.14 interpreter optimizations (10–20% faster than 3.12)
Pandas/Polars ETL	python:3.14-slim	Vectorized ops dominate; image choice minor
BLAS operations (Intel CPU)	intel/python	MKL single-threaded kernels are highly optimized
BLAS operations (AMD CPU)	python:3.14-slim	OpenBLAS performs well on AMD
IO-bound (file/network)	python:3.14-slim	IO dominates; smallest image wins

→ Multi-Threaded Workloads

First, identify your parallelism strategy:

Python Threading (threading, ThreadPoolExecutor)

Workload Type	Python 3.12 (Intel/Anaconda)	Python 3.14 (slim)	Recommendation
IO-bound	✅ Works—GIL released during IO	✅ Works—GIL released during IO	Either; prefer 3.14-slim for size
CPU-bound Python	❌ GIL blocks parallelism	❌ GIL blocks parallelism	Use multiprocessing instead
NumPy/BLAS	✅ MKL has internal threads	✅ OpenBLAS has internal threads	Configure MKL_NUM_THREADS or OPENBLAS_NUM_THREADS

Python Multiprocessing (multiprocessing, ProcessPoolExecutor)

Workload Type	Python 3.12 (Intel/Anaconda)	Python 3.14 (slim)	Recommendation
CPU-bound Python	✅ Bypasses GIL	✅ Bypasses GIL + faster interpreter	python:3.14-slim
Monte Carlo simulations	✅ Works	✅ Works + 10–20% faster per process	python:3.14-slim
Mixed Python/NumPy	✅ MKL helps NumPy portions	✅ Faster Python portions	Benchmark both

Library-Level Parallelism

Library	Threading Mechanism	Configuration	Notes
NumPy (MKL)	Internal MKL threads	MKL_NUM_THREADS=8	Only in intel/python, anaconda
NumPy (OpenBLAS)	Internal OpenBLAS threads	OPENBLAS_NUM_THREADS=8	Default in python:slim
Polars	Rust rayon thread pool	POLARS_MAX_THREADS=8	Independent of Python GIL
Pandas	Mostly single-threaded	N/A	Use Polars for parallel ETL
joblib	Process or thread backend	n_jobs=-1	Choose backend based on workload

---

Step 3: Quick Reference Decision Matrix

START
│
├─► AMD CPU?
│     │
│     └─► YES ──► Use python:3.14-slim (always)
│                   │
│                   ├─► IO-bound? ──► threading OK
│                   ├─► CPU-bound Python? ──► use ProcessPoolExecutor
│                   ├─► BLAS-heavy? ──► set OPENBLAS_NUM_THREADS
│                   └─► ETL pipelines? ──► use Polars for parallelism
│
└─► Intel CPU?
│
├─► BLAS-heavy workload (>50% of runtime)?
│     │
│     ├─► YES ──► Use intel/python or anaconda
│     │             │
│     │             ├─► Set MKL_NUM_THREADS for parallel BLAS
│     │             └─► CPU-bound Python portions? ──► use ProcessPoolExecutor
│     │
│     └─► NO ──► Use python:3.14-slim
│                  │
│                  ├─► IO-bound? ──► threading OK
│                  ├─► CPU-bound Python? ──► use ProcessPoolExecutor
│                  └─► ETL pipelines? ──► use Polars for parallelism
│
└─► Need conda packages?
│
├─► YES ──► Use anaconda (accept 3.5GB image)
└─► NO ──► Use python:3.14-slim

---

Threading and Parallelism Cheat Sheet

When Threading Works (GIL not a bottleneck)

• ✅ File IO (reading/writing files)
• ✅ Network IO (HTTP requests, database queries)
• ✅ Waiting for subprocesses
• ✅ NumPy/SciPy operations (release GIL internally)
• ✅ Polars operations (Rust-based, GIL-free)

When Threading Fails (GIL serializes execution)

• ❌ Pure Python loops with computation
• ❌ String processing in Python
• ❌ Dictionary/list manipulation
• ❌ Custom Python algorithms
• ❌ Pandas .apply() with Python functions

Workarounds for CPU-Bound Python

Approach	Python 3.12	Python 3.14	Notes
ProcessPoolExecutor	✅	✅ (faster)	Each process has own interpreter
multiprocessing.Pool	✅	✅ (faster)	Same as above
joblib with backend='loky'	✅	✅ (faster)	Convenient API
Numba @njit(parallel=True)	✅	✅	JIT compiles to native code
Cython with nogil	✅	✅	Requires compilation
Rewrite in Polars/NumPy	✅	✅	Best if possible

---

4. Benchmark Categories and Tests

The benchmark suite dynamically generates Docker image recommendations by analyzing actual performance data across five workload categories:

• IO-Bound Workloads — Parquet scan, file hashing, compression
• Pandas/Polars ETL — Joins, groupby, resample, aggregations
• NumPy BLAS-Heavy — Matrix ops, SVD, eigenvalue, Cholesky
• Pure Python CPU-Bound — Python loops, Monte Carlo, order book replay
• Real-World Mixed Workloads — Multi-stage ETL pipelines, risk calculations with threading

For each category, the system counts which image wins the most tasks and calculates the performance spread between the fastest and slowest images. The key insight is a 10% threshold rule: if all images perform within 10% of each other, the system recommends the smallest image (python:3.14-slim at ~150MB) over larger alternatives like Anaconda (~3.5GB), prioritizing container efficiency when performance differences are negligible. Special logic applies to BLAS-heavy workloads, where Intel MKL may provide advantages on Intel CPUs—though the report warns that MKL can actually be slower on AMD processors. This data-driven approach ensures recommendations reflect real measured performance rather than assumptions, while favoring lean container images unless a larger specialized image delivers a clear, measurable benefit.

Category 1: IO-Bound Workloads

These tests measure operations dominated by disk and network throughput rather than CPU computation:

• io_parquet_scan: Uses Polars’ lazy evaluation to scan Parquet files and perform simple aggregations. Performance is bound by disk read speed and the Rust-based Polars engine—Python interpreter overhead is minimal.
• io_parquet_roundtrip: Reads a Parquet file with PyArrow, writes it back with Zstandard compression, then reads it again. Tests compression/decompression speed and disk IO.
• io_file_hashing: Computes SHA-256 hashes of data files using chunked reads. This is pure IO-bound work where the GIL is not a bottleneck since threads release it during IO waits.

Expected result: All Docker images perform nearly identically since these operations spend most time waiting for disk/network rather than executing Python code.

Category 2: Pandas/Polars ETL Workloads

Tests covering typical data engineering operations in finance:

• etl_pandas_groupby_join: Loads trades and quotes datasets, performs an inner merge on symbol and timestamp, then computes groupby aggregations. Tests pandas’ C-optimized join and aggregation paths.
• etl_polars_lazy_agg: Performs the same join and aggregation using Polars’ lazy API, which builds an optimized query plan before execution. The Rust engine minimizes Python overhead.
• etl_pandas_resample: Resamples trade data into 5-minute OHLC bars with rolling window calculations—a common hedge fund operation for building trading signals.
• etl_python_feature_loop: Feature engineering using Python for loops over DataFrame rows (computing VWAP, momentum features, urgency classification). This tests raw Python interpreter speed for logic that can’t easily be vectorized.
• etl_polars_python_udf: Applies Python user-defined functions via Polars’ map_elements(), measuring the overhead of calling back into Python from the Rust engine.

Expected result: Performance varies by 5–10% across images. Polars tests show minimal variation; pandas tests may show slight MKL benefits for underlying numerical operations.

Category 3: NumPy BLAS-Heavy Workloads

These tests target the Basic Linear Algebra Subprograms (BLAS) library—where image choice matters most:

• blas_matrix_multiply: Large dense matrix multiplication (DGEMM). Multiplies two 2500×2500 matrices. This is the canonical BLAS benchmark and where MKL optimization is most visible.
• blas_eigenvalue: Eigenvalue decomposition (DSYEV) of a symmetric positive-definite matrix. Used in PCA, covariance analysis, and risk models.
• blas_svd: Singular Value Decomposition of a 2000×800 matrix. Common in factor analysis, dimensionality reduction, and signal processing.
• blas_cholesky: Cholesky decomposition of a positive-definite matrix. Used in portfolio optimization, Monte Carlo simulation, and solving linear systems efficiently.

Expected result: Intel Python with MKL can be 1.1×–2.0× faster than OpenBLAS on Intel CPUs. However, on AMD CPUs, MKL may actually be slower due to its CPU vendor detection code.

Category 4: Pure Python CPU-Bound Workloads

Tests that stress the Python interpreter itself:

• python_cpu_bound: Runs CPU-intensive pure-Python loops (sin/cos/exp calculations) with configurable threading. Measures whether threads provide any speedup (they won’t under the GIL).
• python_threaded_sum: A parallel summation benchmark designed to show threading scalability—or lack thereof under GIL contention.
• python_monte_carlo_var: Monte Carlo Value-at-Risk simulation using ProcessPoolExecutor. Combines Python loops with NumPy operations, testing both interpreter speed and BLAS performance.
• python_orderbook_replay: Simulates processing a stream of order book events with Python dictionaries and loops. This is heavy Python bytecode execution with minimal library calls—pure interpreter overhead.

Expected result: All GIL-enabled images perform similarly for single-threaded work. Multi-process tests show minimal image variation since each process runs independently.

Category 5: Real-World Mixed Workloads

End-to-end pipeline tests simulating production hedge fund jobs:

• realworld_etl_pipeline: A four-stage pipeline: (1) load and merge datasets, (2) compute rolling window features per symbol, (3) parallel symbol processing with ThreadPoolExecutor, (4) final aggregation. Tests the full stack from IO to threading.
• realworld_risk_calc: Portfolio risk calculation running thousands of Monte Carlo scenarios in parallel. Each scenario shocks prices, computes P&L, and aggregates risk metrics. Tests threading efficiency and numerical computation.

Expected result: Performance is similar across images since these workloads combine IO, vectorized pandas, and multi-processing—areas where image choice has minimal impact.

---

5. Understanding the Global Interpreter Lock (GIL)

What Is the GIL?

The Global Interpreter Lock (GIL) is a mutex (mutual exclusion lock) in CPython—the reference Python implementation—that allows only one thread to execute Python bytecode at any given time. Even on a 64-core server, a multi-threaded Python program can only run Python code on one core at a time.

The GIL exists because CPython’s memory management (reference counting) is not thread-safe. Without the GIL, concurrent threads could corrupt reference counts, leading to memory leaks or use-after-free crashes. The GIL is a simple, effective solution that made CPython easy to implement and extend, but it fundamentally limits multi-threaded parallelism for CPU-bound Python code.

When the GIL Matters (and When It Doesn’t)

Workload Type	GIL Impact	Workaround
CPU-bound Python loops	Severe—threads serialize	Use multiprocessing or ProcessPoolExecutor
IO-bound operations	Minimal—GIL released during IO	Threading works fine
C extension code	Depends—well-written extensions release the GIL	NumPy, pandas, Polars all release GIL during heavy ops
BLAS/LAPACK	None—MKL/OpenBLAS have internal thread pools	Configure via MKL_NUM_THREADS, etc.

Free-Threaded Python: The Future

Python 3.13 introduced experimental free-threaded builds (PEP 703) that disable the GIL entirely, enabling true multi-threaded parallelism. Python 3.14 continues this work with improved stability and performance.

Why this benchmark doesn’t use free-threaded Python:

The free-threaded build requires all C extensions to be rebuilt with thread-safe memory management. As of late 2024, NumPy is not yet compatible with free-threaded Python. Since NumPy is fundamental to every workload in this benchmark suite (and to virtually all data science work), using free-threaded builds would mean:

1. NumPy wouldn’t work at all, or
2. We’d need experimental, unsupported NumPy builds that may have correctness issues

Other critical libraries (pandas, scikit-learn, PyArrow) also lack free-threaded support. Until the ecosystem catches up—likely Python 3.15 or 3.16—production workloads must use standard GIL-enabled Python.

Bottom line: The GIL remains a constraint for this benchmark. We use ProcessPoolExecutor (multi-processing) rather than ThreadPoolExecutor (multi-threading) for CPU-bound parallelism, which bypasses the GIL by running separate Python interpreters.

---

6. Understanding BLAS and MKL

BLAS (Basic Linear Algebra Subprograms) is a standardized API for fundamental linear algebra operations: vector addition, scalar multiplication, dot products, and matrix operations. When you call numpy.dot(), numpy.linalg.svd(), or @ for matrix multiplication, NumPy delegates to a BLAS implementation rather than using pure Python loops. BLAS implementations are heavily optimized with hand-tuned assembly, SIMD vectorization (SSE, AVX, AVX-512), cache blocking, and multi-threading—achieving performance that pure Python could never match.

OpenBLAS is the default BLAS library in most Python distributions, including the official python:slim images. It’s open-source, vendor-neutral, and performs well across Intel, AMD, and ARM processors. OpenBLAS auto-detects your CPU at runtime and selects appropriate optimizations.

Intel Math Kernel Library (MKL) is Intel’s proprietary BLAS implementation, highly optimized for Intel processors. MKL uses Intel-specific instructions and microarchitecture knowledge to extract maximum performance from Xeon and Core CPUs. For dense matrix operations on Intel hardware, MKL can be 10–100% faster than OpenBLAS, with the gap widening for larger matrices and operations that benefit from AVX-512.

The AMD caveat: MKL includes CPU vendor detection code that historically throttled performance on non-Intel processors. While Intel has improved this behavior, MKL on AMD Ryzen/EPYC may still underperform compared to OpenBLAS. Always benchmark on your actual hardware before committing to an MKL-based image in production.

---

7. Miniconda vs. Anaconda: Why We Chose Anaconda

Miniconda and Anaconda are both conda-based Python distributions from Anaconda, Inc., and they use the same package repositories, the same conda solver, and the same default BLAS configuration (MKL). The only difference is what’s pre-installed:

• Miniconda (~400MB): Minimal installation with just Python, conda, and essential dependencies. You install everything else yourself.
• Anaconda (~3.5GB): “Batteries included” distribution with 250+ pre-installed data science packages (NumPy, pandas, scikit-learn, Jupyter, matplotlib, etc.).

For benchmarking purposes, the images yield identical performance because:

1. Both use the same NumPy builds linked against Intel MKL
2. Both use the same Python interpreter from conda-forge
3. Both have the same threading and BLAS configuration

We chose continuumio/anaconda3 for the benchmark because:

• It represents the “maximum convenience” end of the spectrum—teams who choose Anaconda typically value having packages pre-installed over image size
• The larger image size (3.5GB vs ~400MB for Miniconda) is the realistic tradeoff users face
• It’s the most commonly used conda-based image in enterprise data science environments

If you’re optimizing for image size but want conda’s package management, Miniconda would give you identical runtime performance in a smaller package—but you’d need to install your dependencies, which adds build time and complexity. For production deployments where image size matters, python:slim with pip is typically a better choice than either conda variant.

---

8. Docker Images Compared

python:3.14-slim (~150MB)

The lightweight official Python image offers the smallest footprint and fastest container cold-start times, making it ideal for CI/CD pipelines and serverless deployments. It ships with OpenBLAS for NumPy operations and benefits from the latest CPython interpreter optimizations, which can significantly speed up pure-Python workloads like order book replay or Monte Carlo simulations. On both Intel and AMD CPUs, performance is consistent since OpenBLAS doesn’t discriminate by vendor. The tradeoff is that you must install all dependencies yourself, and BLAS-heavy linear algebra workloads may lag behind MKL-optimized images on Intel hardware.

intel/python:latest (~2.8GB)

Intel’s distribution bundles NumPy linked against Intel Math Kernel Library (MKL), which is highly optimized for Intel processors. This image excels at dense linear algebra operations (matrix multiplication, SVD, eigenvalue decomposition) and multi-threaded numerical workloads like joblib-based simulations. However, MKL includes CPU vendor checks that can throttle performance on AMD Ryzen/EPYC processors—in some cases making it slower than OpenBLAS on AMD hardware. The image is also significantly larger than the slim variant, increasing pull times and storage costs. Choose this image when running BLAS-heavy finance workloads on Intel Xeon or Core processors.

continuumio/anaconda3:latest (~3.5GB)

The Anaconda distribution provides the broadest compatibility with thousands of pre-installed data science packages and conda-managed environments. It uses MKL by default for NumPy, giving it similar BLAS performance characteristics to Intel Python on Intel CPUs. The main advantages are convenience (batteries included) and reproducibility via conda environments. The downsides are the largest image size of the three, slower container startup, and the same potential AMD performance penalty from MKL. This image suits teams who value a rich pre-configured environment over minimal container size, or who need packages that are difficult to install via pip.

---

9. Single-Threaded vs. Multi-Threaded Performance

The benchmark suite runs each test at two thread configurations (1 thread and 8 threads) to answer a critical question: when does parallelism actually help? The answer depends heavily on the workload type and Python’s Global Interpreter Lock (GIL).

The GIL and Threading Reality

Python’s GIL allows only one thread to execute Python bytecode at a time. This means:

• CPU-bound Python code: Threading provides no speedup and may even slow down due to context-switching overhead. Running 8 threads on a pure Python loop still executes sequentially.
• IO-bound code: Threading works well because threads release the GIL while waiting for disk/network operations. File hashing and Parquet scanning scale with threads.
• C extension code: Libraries like NumPy release the GIL during heavy computations, so BLAS operations can utilize multiple cores even with threading.

What the Benchmarks Show

The report generates a “When to Use Single-Threaded vs Multi-Threaded” comparison table showing the speedup ratio between 1-thread and 8-thread runs:

Speedup	Interpretation	Examples
< 0.9×	Single-threaded is faster—threading overhead dominates	Small matrix operations, short-running Python loops
0.9×–1.2×	Similar performance—either configuration works	Pandas groupby, Polars lazy aggregations
> 1.2×	Multi-threaded is faster—parallelism provides real benefit	Large BLAS operations, IO-bound hashing, multi-process Monte Carlo

Category-Specific Threading Behavior

IO-Bound Workloads: Threading helps significantly because threads release the GIL during IO waits. File hashing with 8 threads can approach 4–8× speedup depending on disk throughput.

Pandas/Polars ETL: Mixed results. Polars uses its own Rust-based thread pool (independent of Python’s GIL), so it benefits from POLARS_MAX_THREADS. Pandas operations are mostly single-threaded C code, so adding Python threads doesn’t help.

BLAS-Heavy Workloads: NumPy releases the GIL during BLAS calls, and both MKL and OpenBLAS have internal thread pools. Setting MKL_NUM_THREADS=8 or OPENBLAS_NUM_THREADS=8 enables parallel matrix operations. The benchmark controls these via environment variables.

Pure Python CPU-Bound: With standard (GIL-enabled) Python, threading provides ~1.0× speedup—threads serialize on the GIL. This is where free-threaded Python builds would shine, but the images tested here are standard GIL builds.

Real-World Mixed Workloads: These pipelines use ThreadPoolExecutor for parallel symbol processing and ProcessPoolExecutor for CPU-heavy Monte Carlo scenarios. Multi-processing bypasses the GIL entirely (separate Python interpreters), so these tests scale well with core count regardless of image choice.

Key Takeaways

1. Don’t blindly add threads—measure first. Some workloads get slower with threading overhead.
2. Use processes for CPU-bound work—ProcessPoolExecutor or multiprocessing bypasses the GIL entirely.
3. Configure library thread pools—set OMP_NUM_THREADS, MKL_NUM_THREADS, etc. to control BLAS parallelism separately from Python threading.
4. IO-bound code threads well—file operations, network calls, and database queries can use threading effectively.

---

10. Python Version Evolution: What Changed from 3.12 to 3.14

The Docker images in this benchmark span different Python versions, each bringing significant performance and compatibility changes that directly impact benchmark results.

Intel Python and Anaconda: Stuck on Python 3.12

As of late 2024, both intel/python:latest and continuumio/anaconda3:latest ship with Python 3.12.x. These distributions lag behind the official Python release cycle because:

1. NumPy/SciPy compatibility testing—Intel validates MKL integration extensively before releasing new Python versions
2. Conda ecosystem coordination—thousands of conda-forge packages must be rebuilt and tested
3. Enterprise stability requirements—their user base prioritizes stability over bleeding-edge features

Python 3.12 Key Features (October 2023):

• Per-interpreter GIL (PEP 684)—each subinterpreter can have its own GIL, enabling true parallelism for embedded Python
• Immortal objects (PEP 683)—reduced reference counting overhead for common objects like None, True, small integers
• Comprehension inlining—list/dict/set comprehensions execute faster by avoiding function call overhead
• Improved error messages—more precise tracebacks and suggestions

These optimizations provided 5–15% speedups for typical Python code compared to 3.11.

Python 3.13: The Free-Threading Preview (October 2024)

Python 3.13 introduced experimental support for free-threaded Python (PEP 703), allowing true multi-threaded parallelism by disabling the GIL. Key changes:

• Optional GIL-free build—compile with --disable-gil or use special Docker images tagged python:3.13-slim-nogil
• Biased reference counting—new memory management scheme that works without the GIL
• Deferred reference counting—objects can avoid reference count updates in many cases
• JIT compiler foundation—experimental copy-and-patch JIT compiler (off by default)

Performance impact: The free-threaded build has ~5–10% single-threaded overhead due to more complex reference counting, but CPU-bound multi-threaded code can see 2–8× speedups by utilizing all cores.

Python 3.14: Interpreter Optimizations (October 2025)

The python:3.14-slim image in this benchmark represents the latest stable Python release with significant interpreter improvements:

• Tail-call optimization for bytecode—reduced function call overhead, especially for recursive algorithms
• Improved adaptive specialization—the interpreter learns hot code paths and optimizes them more aggressively
• Better inline caching—attribute lookups and method calls are faster after warmup
• Reduced memory allocator overhead—optimized small object allocation patterns
• Enhanced dead code elimination—the compiler removes more unreachable code paths

Performance impact: Pure Python code (loops, function calls, attribute access) runs 10–20% faster than Python 3.12. This is visible in benchmarks like python_orderbook_replay and etl_python_feature_loop where Python bytecode execution dominates.

How This Affects Benchmark Results

Workload Type	Intel/Anaconda (3.12)	Python 3.14-slim
BLAS-heavy (matrix ops)	Faster—MKL optimization	Slower—OpenBLAS, older BLAS code paths
Pure Python loops	Slower—older interpreter	Faster—3.14 bytecode optimizations
Pandas/Polars ETL	Similar—C/Rust code dominates	Similar—library code is Python-version agnostic
IO-bound	Similar—kernel/driver bound	Similar—no Python overhead

The tension between MKL’s linear algebra advantage (favoring Intel/Anaconda) and 3.14’s interpreter speed (favoring python:slim) explains why different categories recommend different images:

• BLAS-heavy → Intel Python (MKL wins by 10–100%)
• Pure Python → python:3.14-slim (interpreter wins by 10–20%)
• Everything else → python:3.14-slim (smallest image, performance within 10%)

Looking Ahead: Free-Threaded Python in Production

While this benchmark uses standard GIL-enabled builds, Python 3.13+ free-threaded builds are maturing rapidly. By Python 3.15 (expected October 2026), free-threaded Python may become production-ready, which would:

1. Eliminate the “use processes for CPU-bound work” workaround—threading would provide true parallelism
2. Favor python:slim even more—no need for MKL’s multi-threaded BLAS when Python itself can parallelize
3. Change how we write concurrent code—ThreadPoolExecutor would become viable for CPU-bound tasks

For now, the recommendation remains: benchmark on your actual workload and hardware, but default to the smallest image unless you have proven BLAS-heavy workloads running on Intel CPUs.

---

11. Conclusion

Selecting a Docker base image for Python data workloads doesn’t have to be guesswork. This benchmark suite provides empirical, reproducible data to guide your decision:

1. Default to python:3.14-slim—smallest image (~150MB), fastest pulls, consistent performance across CPU vendors, and latest interpreter optimizations.
2. Consider intel/python only for BLAS-heavy workloads on Intel CPUs—matrix multiplication, SVD, eigenvalue decomposition, and similar linear algebra operations can see 10–100% speedups with MKL. But verify on your hardware first—MKL can be slower on AMD.
3. Use Anaconda for convenience, not performance—if your team needs conda environments or pre-installed packages, Anaconda won’t hurt performance, but the 3.5GB image size has real costs in CI/CD and deployment.
4. Measure threading impact per workload—some tasks get faster with parallelism, others get slower. The benchmark’s 1-thread vs. 8-thread comparison helps identify which is which.
5. Watch for free-threaded Python maturity—once NumPy and the ecosystem support it, free-threaded Python will change the calculus significantly in favor of lightweight images.

Run the benchmarks on your own infrastructure with your actual workloads. The code is open source and designed to be extended with your own tasks. The best Docker image is the one that performs best for your specific use case—and now you have the tools to find out which one that is.

---

Benchmark suite available at: github.com/jiripik/finance-python-bench