Mohammad Raziei

Posted on Apr 6

Why I Built pip-size: A Story About Obsession with Performance

#python #programming #showdev #opensource

It Started with a Simple Question

"How fast is it?"

That's the question I always ask when I write a Python package. Not "does it work?" — because obviously it works. The real question is: how fast is it compared to what already exists?

I've been building high-performance Python libraries for years. Libraries like:

yyaml — a YAML parser
pygixml — an XML parser
serin — a serialization library
ctoon — a image processing library
novasvg — an SVG parser
liburlparser — a URL parser

And the results? In many cases, 20x to 100x faster than the mainstream alternatives.

I have the benchmarks to prove it. I've spent countless hours profiling, optimizing, and benchmarking. I know exactly how fast my code runs.

But there was one question I couldn't answer easily:

"How big is it?"

The Problem Nobody Talks About

When you compare Python packages, everyone talks about:

Features
API simplicity
Community support
GitHub stars

But nobody talks about download size. And that's a problem.

Here's why: a package might be "lightweight" in source code, but its dependencies tell a different story.

Let me give you a real example. A few months ago, I was comparing HTTP libraries:

requests==2.33.1  63.4 KB  (total: 620.4 KB)
httpx==0.28.1  71.8 KB  (total: 560.0 KB)
aiohttp==3.13.5  1.7 MB  (total: 2.6 MB)

The package itself is small. But the total size tells a different story.

Now imagine you're choosing between two libraries:

Library A: 50 KB package, but pulls in 500 KB of dependencies
Library B: 200 KB package, but zero dependencies

Which one is really "lighter"?

That's the question I wanted to answer. But there was no tool to do it.

The Search for a Solution

I searched for existing tools. I found:

pip show — shows installed package size, but only for what's already installed
pip download — downloads everything to measure it (wasteful!)
Various size calculators — none of them considered the full dependency tree

The problem? You have to install the package to see its size. That's insane!

I wanted to know the size before installing. I wanted to see the full picture — the package plus every dependency, transitively.

So I did what any developer would do: I built it myself.

Introducing pip-size

pip-size calculates the real download size of PyPI packages and their dependencies. Zero downloads. No pip subprocess. Pure PyPI JSON API.

pip install pip-size

pip-size requests

🔍 Resolving 'requests'...
  ✓ requests==2.33.1  →  requests-2.33.1-py3-none-any.whl
    ✓ idna==3.11  →  idna-3.11-py3-none-any.whl
    ✓ certifi==2026.2.25  →  certifi-2026.2.25-py3-none-any.whl
    ✓ charset_normalizer==3.4.7  →  charset_normalizer-3.4.7-py3-none-any.whl
    ✓ urllib3==2.6.3  →  urllib3-2.6.3-py3-none-any.whl
  requests==2.33.1  63.4 KB  (total: 620.4 KB)
  ├── idna==3.11  69.3 KB
  ├── certifi==2026.2.25  150.1 KB
  ├── charset_normalizer==3.4.7  209.0 KB
  └── urllib3==2.6.3  128.5 KB

Now you can see:

The package size (63.4 KB)
The total size including all dependencies (620.4 KB)
The breakdown of each dependency

Features

Full dependency tree — see every transitive dependency
Extras support — check requests[security] or fastapi[standard]
JSON output — integrate with scripts
Proxy support — for restricted networks
Caching — 24-hour cache to avoid repeated requests

Why This Matters

When I'm developing high-performance libraries, size matters for several reasons:

1. Deployment

If you're shipping to edge devices, every megabyte counts. A library that claims to be "lightweight" but pulls in 500 MB of dependencies is not lightweight — it's a liability.

2. Cold Starts

In serverless environments (AWS Lambda, Google Cloud Functions), cold start time correlates with package size. Smaller packages = faster cold starts.

3. CI/CD

Smaller packages mean faster pip installs in your CI pipeline. Over hundreds of builds, this adds up.

4. User Trust

As a package maintainer, I want to be transparent about what I'm shipping. If my package is 100 KB but pulls in 50 MB of dependencies, users deserve to know.

The Bigger Picture

Building pip-size made me realize something: we've been comparing packages wrong.

When we see "package X is 50 KB" and "package Y is 200 KB," we assume X is lighter. But that's only half the story.

The real cost of a package is:

package size + size of all dependencies + size of their dependencies + ...

That's what pip-size reveals.

What's Next

I'm continuing to improve pip-size. Some ideas:

Compare multiple packages side-by-side
Show size trends over time
Integrate with dependency security tools
Add "size budget" warnings for CI

If you have ideas or want to contribute, the repo is open: github.com/mohammadraziei/pip-size

Final Thoughts

I've spent years optimizing for speed. Now I'm obsessed with size too.

Because at the end of the day, performance isn't just about how fast code runs — it's about how efficiently it reaches your users.

Have you ever been surprised by a package's hidden size? Let me know in the comments!

Links:

GitHub: github.com/mohammadraziei/pip-size
PyPI: pypi.org/project/pip-size

DEV Community