Performance Analysis of Python's Dict() and {}

https://madebyme.today/blog/python-dict-vs-curly-brackets/

by nathiss • 2 years ago

108 92 2 years ago

pphysch2• 2 years ago

The first "benchmark" shows dict() being twice as fast, but the rest of the article concludes "The {} is always faster than dict."

michaelhoffman• 2 years ago

I wonder if they swapped the benchmark results somehow. Because on my computer, I get roughly the same times but with {} twice as fast as dict().

nathiss• 2 years ago

Yes, you're absolutely right. I apologize for this copy-paste mistake. It's fixed now.

Epa095• 2 years ago

Damb am I happy you commented this! I saw the same, checked it twice, and a final time before posting. But then the results were suddenly as expected (dict() being slower). At least I am not going mad, he must have changed it just now.

bigbillheck• 2 years ago

The difference is 20ns, and if that's enough for you to care about you've got much bigger worries (like "using python").

IshKebab• 2 years ago

I agree. If you're benchmarking this then you're using the wrong language.

But I hadn't considered the fact that `dict` can be overridden. That was interesting.

frakt0x90• 2 years ago

I guess I see this post as more about profiling, discovering unintuitive differences, and exploring python internals than offering 20ns optimizations. I personally appreciated it.

sjwhevvvvvsj2• 2 years ago

(+20ns x # calls made) can be significant if you’re dealing with billions of executions though.

If nothing else a search/replace for “dict()” to “{}” could yield an aggregate performance bump with basically zero refactoring cost.

Also re Python in general: love it or hate it, it “won” as the language of ML. If you want to use ML libraries you’ll be in python.

ayhanfuat2• 2 years ago

If you are building billions of dicts, the bottleneck will not be how you initialize them as empty dicts for sure.

arsome• 2 years ago

Yeah I would be much more concerned about things which cause exponential time increases, like developers who brute force search lists instead of using dictionaries than how they declare their dictionaries unless I was at the point of profiling and the dict() constructor was somehow near the top of the list.

queuebert• 2 years ago

I have a book on the shelf called "High Performance Python".

Seriously, though, if every Python program in the world was 0.1% faster, that would probably save a lot of energy.

viraptor• 2 years ago

You have to compare that to the amount of energy spent while making it 0.1% faster. On average, I'm not sure we'd be saving any energy. The one bit that would get any remotely relevant gain would be offset by lots of tools where that improvement happens once a week.

How many minutes / how much energy would it take you to setup a project, run a profiler, do the fix, run tests/CI, commit, release, etc. -vs- how much energy would that 0.1% change save over years?

nomel• 2 years ago

Bring globals into local scope, never use '.' in tight loops, avoid function calls, etc [1], sure make ugly python code. But, wow, it really can make a difference.

[1] https://wiki.python.org/moin/PythonSpeed/PerformanceTips

ezo• 2 years ago

I’m wonder, who’s thinking that dict() is more readable???

shoo• 2 years ago

`{x, y}` is the set containing the two elements `x` and `y`, `{x}` is the set containing only the element `x`, so "surely `{}` is the empty set" !

pdonis• 2 years ago

If Python had had built-in set notation from the start, {} might indeed have been a notation for an empty set instead of an empty dict.

However, Python didn't even have sets at all until version 2.3, and they were in a stdlib module instead of being a built-in type until version 2.6. By that time dict notation was well entrenched.

colpabar2• 2 years ago

You could argue that since `{}` is also technically an empty set, `dict()` is more explicit.

masklinn4• 2 years ago

Except `{}` is never an empty set.

pwdisswordfishc2• 2 years ago

The empty set is `{*()}`.

nerdponx• 2 years ago

dict() can be useful for enforcing (or indicating to the reader) that keys are strings and valid Python identifiers. {} allows arbitrary keys, as long as the data type is hashable.

wirrbel• 2 years ago

less clutter for string-only keys.

kevincox• 2 years ago

For string keys it can be as it is `dict(a=1, b=2, c=3)` vs `{"a": 1, "b": 2, "c": 3}`. There is a lot of `"` noise on the latter.

formerly_proven• 2 years ago

50% less noise with ‘ though dict is still slightly easier to read; you can also convey that the keys are supposed to be valid identifiers.

paulddraper3• 2 years ago

Of course, for anything except string keys, that isn't even an option.

locuscoeruleus• 2 years ago

I think dict(name=name, age=age) can be definitely be more readable and ergonomical to write than {"name": name, "age": age}.

mikepurvis• 2 years ago

I still miss coffeescript's ability to do dict(@name, @age) though I understand that it creates an unwelcome coupling between the parameter names and their names in the calling scope.

For my part, those names are often the same anyway, though, since the calling scope names are often arbitrary and might as well match the parameter names.

empiko2• 2 years ago

I think it's more readable. It matches with the type name, it is consistent when you define different structures (list, set, dict vs [], set, {}), you can pass it as a function, etc. [] and {} is unnecessary syntax sugar, not to mention how the same parentheses are overloaded when sets are defined.

munch117• 2 years ago

I do. dict() costs me less eye strain to recognise out of the corner of my eye.

Why the triple question marks? You could have just asked the question straight.

pphysch2• 2 years ago

One place where I prefer dict() is where dicts are used as "nested kwargs", e.g. in Django's ORM for passing default values.

    User.objects.get_or_create(
      username="bob",
      defaults=dict(
        email="bob@example.com",
      )

this makes it easy to move fields between `defaults` and `kwargs`. Granted, you could achieve the same isomorphism with ** operator, but less readably IMO.

trostaft• 2 years ago

Unless I've misunderstood the comparison, the lists example does not appear to be comparing apples to apples. Reproducing here:

  $ python -m timeit "list((1, 2, 'a'))"
  5000000 loops, best of 5: 53 nsec per loop
  $ python -m timeit "[(1, 2, 'a')]"
  10000000 loops, best of 5: 30.4 nsec per loop

The first command produces a list of three elements, whereas the second produces a list of one element (being the tuple).

masklinn4• 2 years ago

You are correct.

To µbench this, you'd want to use `-s` to set up the base object which both snippets then convert.

    > python -m timeit -s "t = (1, 2, 'a')" "list(t)"
    10000000 loops, best of 5: 39.8 nsec per loop
    > python -m timeit -s "t = (1, 2, 'a')" "[*t]"
    10000000 loops, best of 5: 25.1 nsec per loop
    > python -m timeit -s "[1, 2, 'a']"
    50000000 loops, best of 5: 4.28 nsec per loop

(this is 3.11.2 on an M1 Pro)

charlieyu1• 2 years ago

The third method should be clearly the fastest one, the other two we are building a tuple then convert to a list

tczMUFlmoNk2• 2 years ago

Shouldn't you omit `-s` in the last one? I think you're just effectively testing an empty loop, since you're only actually creating the list in the setup phase.

On my machine, the tests that actually do work are:

    $ python3 -m timeit -s 't = (1, 2, "a")' 'list(t)'
    5000000 loops, best of 5: 44.8 nsec per loop
    $ python3 -m timeit -s 't = (1, 2, "a")' '[*t]'
    10000000 loops, best of 5: 22.9 nsec per loop
    $ python3 -m timeit '[1, 2, "a"]'
    10000000 loops, best of 5: 23.1 nsec per loop

...compared to the empty ones:

    $ python3 -m timeit -s '[1, 2, "a"]'
    50000000 loops, best of 5: 5.43 nsec per loop
    $ python3 -m timeit ''
    50000000 loops, best of 5: 5.8 nsec per loop

(11th gen Intel i7 laptop, Python 3.10.6)

t8sr5• 2 years ago

While it points at interesting questions about Python's internals, I hope people writing Python realize that optimizing it is pointless, except for cases where you change the complexity class of an algorithm.

The performance of pure python code is orders of magnitude worse than non-interpreted languages, there's no point trying to shave off 0.5% off a 5000% difference.

pyuser5832• 2 years ago

It’s also pointless because Python internals have no guarantees.

Changing version or even platform can change the absolute efficiency.

H8crilA2• 2 years ago

(I generally agree that everyone should almost always choose the more readable version)

In this case the speed difference will likely always be there, since `dict()` can be overriden (monkey-patched) - hence the interpreter needs to resolve it at runtime.

Spivak• 2 years ago

This logic makes no sense, you're saying that trying to boost performance by small increments 0-10% isn't worthwhile on a Civic because it'll never be a Bugatti? That's the least helpful advice when you have a real-life application written in Python and want to get some easy wins on your tight loops.

Also Python internals do have some guarantees but in this case it's a semantic guarantee. Because builtins can be shadowed you'll always have to pay the performance cost of looking them up which isn't true for {}.

geysersam• 2 years ago

It's unlikely to make an important difference. That's why it's a bad idea to spend time on it. It's much more likely there are other more impactful changes you can do to improve performance, changing the algorithm or using another better tool for the job.

attractivechaos• 2 years ago

I think the analogy is more like: why open a can with a better screwer when you can open it with a can opener. Use the right tool for the right task.

willseth• 2 years ago

You're off by at least an order of magnitude, and a very common class of performance problems that exists in any language is copying and allocating memory. Python is no different, and there are plenty of facilities to address that and other normal performance issues. If you're talking strictly about CPU bound performance problems, that's a bit of a red herring considering there is an entire ecosystem of Python tools to write performant CPU bound code.

t8sr5• 2 years ago

A little late to reply, but you're of course right, there's no direct way to compare the performance. Python serves (among others) a niche, where it's basically the glue between highly optimized C libraries like numpy. If you're writing that kind of CPU bound code, Python just passes blocks of memory around and it's fine for that. I think this is what you're talking about.

I think outside of that niche, though, there are places where people are writing heavily CPU bound code in Python, because it is so easy to become CPU bound. Case in point: I recently sped up an ML ingestion pipeline by multiple thousands of percent by switching from a pure-python PDF library to one that wraps a .so written in C.

So my point, restated: if you're CPU bound in pure Python code and you have time to try and optimize it, just rewrite the critical section in C and use the FFI. This is how 90% of "Python" libraries get implemented anyway. Compared to this, trying to make Python code more CPU efficient is a waste of time.

By the way, I have done work on CPU performance optimizations in Go, Rust and C, and the things you'd typically do are not possible in Python anyway. You're basically left with randomly tweaking the code until the benchmark gives a thumbs up, because it hit on some cpython idiosyncrasy that will completely change around a few versions later.

einpoklum• 2 years ago

If optimization were pointless I'd be out of a job tomorrow.

(My current day job is doing GPU optimization on iterative medical image reconstruction computation. But of course, I don't do that in Python.)

t8sr5• 2 years ago

I don't mean optimization is pointless, I mean trying to optimize Python code for CPU performance is pointless. If you're going to spend the time to do that, just rewrite the critical section in a reasonable language, then wrap it in an FFI and use that. Optimize the C code if you need to.

shiandow• 2 years ago

I know hasty optimisation is the root of all evil, but even so this has got to be a bit too far in the other direction.

A 2x speed improvement is very significant if it happens to be in the critical loop of your code. You want a 5000% difference? Just find 6 tweaks like these and you might just get there.

Of course in most cases whatever you're doing to build the dict is more likely taking up most of the time, not building the dict itself, but understanding why one option is 2x as fast is still important. Though one can only hope that it will soon be irrelevant when JITed python becomes a thing.

pi-e-sigma• 2 years ago

A 2x speed improvement is very significant if it happens to be in the critical loop of your code. You want a 5000% difference? Just find 6 tweaks like these and you might just get there.

Optimizations don't compound like this.

remus• 2 years ago

Optimisation isn't necessarily handwritten assembly, sometimes you just need to squeeze a little extra juice out of your current setup whether that happens to be a python application or some c code.

t8sr5• 2 years ago

Sure, but if it's a python application, you have two options:

1) Tweak the code without understanding* of how it'll affect performance, because every single line of code hides behind it such complexity that any improvement you find is almost certainly overfitted to your version of Python. Eventually a benchmark will spit out a nice number. If successful, make a modest improvement, maybe 30%.

2) Rewrite the critical section in C. If you need to optimize further, you are now able to draw on 50 years of know-how in a well-studied field. The improvement will be on the order of thousands of percent.

They both take about the same amount of time. Why should you do (1)?

* There is a difference between random tips like "replace {} with dict()" and fundamentals like how the CPU cache works, or the branch predictor. The former is almost certainly a quirk of the current Python version, the latter has been the same for the past 20-30 years. If you do work on software performance, you rely on your knowledge of the fundamentals and a tool like `perf` to make educated guesses about where you can save some cycles. These fundamentals are basically irrelevant to Python code and so you have to make effectively random attempts.

uses• 2 years ago

Understanding how python's data structures work is actually really important and can make the difference between an algorithm completing in microseconds vs "basically never". Performance problems in python are going to come down to these crucial factors of when to use a set vs list vs dict or a dataframe or something else. The fact that it's interpreted is just not that significant compared to how data structures are set up and operated on. People are using python to explore and manipulate very large data - it's the most popular language for doing so.

sweezyjeezy• 2 years ago

I don't think this will refute the article, but I would have found it more convincing if the benchmark had included a single setitem assignment as well, to be sure that the difference wasn't python doing a lazy dict-or-set type assignment on {}

extasia• 2 years ago

I've also had this thought, but found that inspecting the type shows its by default a dictionary, and that it only is interpreted as a set if you treat it as such (eg add comma-seperated elements when instantiating)

assert type({}) == type(dict())) assert type({1,2,3} == type(set())

ayhanfuat2• 2 years ago

From Alex Martelli , a prominent Python expert [1]:

I'm one of those who prefers words to punctuation -- it's one of the reasons I've picked Python over Perl, for example. "Life is better without braces" (an old Python motto which went on a T-shirt with a cartoon of a smiling teenager;-), after all (originally intended to refer to braces vs indentation for grouping, of course, but, hey, braces are braces!-).
"Paying" some nanoseconds (for the purpose of using a clear, readable short word instead of braces, brackets and whatnots) is generally affordable (it's mostly the cost of lookups into the built-ins' namespace, a price you pay every time you use a built-in type or function, and you can mildly optimize it back by hoisting some lookups out of loops).
So, I'm generally the one who likes to write dict() for {}, list(L) in lieu of L[:] as well as list() for [], tuple() for (), and so on -- just a general style preference for pronounceable code. When I work on an existing codebase that uses a different style, or when my teammates in a new project have strong preferences the other way, I can accept that, of course (not without attempting a little evangelizing in the case of the teammates, though;-).

[1] https://stackoverflow.com/a/2745292/2285236

mgraczyk• 2 years ago

I find {} much more readable then dict() because the former is more common.

On the other hand list(L) more readable than L[:] because the fact that slicing copies is more obscure, and these are not equivalent when L is not a list.

My take would be to ignore performance and generally do what is more commonly done.

nephanth• 2 years ago

My problem with {} is that the syntax for dicts {x1:y1, x2:y2 ...} and sets {x1, x2 ...} Are very close, and {} is slightly ambiguous.

I've run into bugs because i wrote {} for the empty set. Since then i write dict() and set()

grumpyprole• 2 years ago

I'm one of those who prefers words to punctuation

It's not punctuation, it's notation. Notation is often essential for readability, we use it for mathematics and music for a very good reason. Consider why JSON is generally preferred to XML. While this guy might have a preference for pointless verbosity, most likely the person who needs to read his code won't.

mgaunard• 2 years ago

does your colleague also uses list instead of []?

If you're in Python, you should embrace the syntax.

justinl33• 2 years ago

Best way to optimize a python dict is to switch languages and use a dict there

paulddraper3• 2 years ago

Your perf will get killed by overhead.

__loam5• 2 years ago

Python is filled with these kinds of traps where there's more than one way to do the same thing but one way is faster for no reason. It's such a bad language.

encomiast• 2 years ago

Compared to what?

__loam5• 2 years ago

Go for example has fewer ways to write things. With Python, you have to guess what the idiomatic pattern is and it's often not obvious and specific to python. Go went as far removing the ternary operator to cut down on this kind of thing. Writing things in the idiomatic way is more obvious because there's usually only one way to do a given thing.

Sohcahtoa824• 2 years ago

Every language has these.

In C/C++, which is faster:

i++;

++i;

These days, a decent compiler will output the same machine code, but it wasn't always true, and ++i was faster.

And really, the "dict() vs {}" performance issue can probably get fixed by the interpreter, but it's such a micro-optimization that it's not worth the time and effort.

__loam5• 2 years ago

I think C++ actually has a very similar problem here, the complexity is worse but I'd bet the runtime isn't an issue because, as you said, the compiler should handle it. The specific problem here is that python has multiple ways to do things that seem pretty much equivalent but that have different run times. Another example is for loops, list comprehensions, and map. All of these things iterate over a collection but all have different run times. That does not make much sense imo.

wyldfire• 2 years ago

A previous analysis of the same question (2.7, 2012): https://doughellmann.com/posts/the-performance-impact-of-usi...

Cannabat• 2 years ago

If you want to implement the suggested changes across your codebase, you can use the `flake8` plugin `flake8-comprehensions`, or `ruff`'s `C4` ruleset, which is an implementation of `flake8-comprehensions`.

Performance Analysis of Python's Dict() and {}

Related Stories