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

Unless I&#x27;ve misunderstood the comparison, the lists example does not appear to be comparing apples to apples. Reproducing here:<p><pre><code> $ python -m timeit &quot;list((1, 2, &#x27;a&#x27;))&quot; 5000000 loops, best of 5: 53 nsec per loop $ python -m timeit &quot;[(1, 2, &#x27;a&#x27;)]&quot; 10000000 loops, best of 5: 30.4 nsec per loop </code></pre> The first command produces a list of three elements, whereas the second produces a list of one element (being the tuple).

I don&#x27;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&#x27;t python doing a lazy dict-or-set type assignment on {}

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

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

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

The difference is 20ns, and if that&#x27;s enough for you to care about you&#x27;ve got much bigger worries (like &quot;using python&quot;).

A previous analysis of the same question (2.7, 2012): <a href="https:&#x2F;&#x2F;doughellmann.com&#x2F;posts&#x2F;the-performance-impact-of-using-dict-instead-of-in-cpython-2-7-2&#x2F;" rel="nofollow">https:&#x2F;&#x2F;doughellmann.com&#x2F;posts&#x2F;the-performance-impact-of-usi...</a>

does your colleague also uses list instead of []?<p>If you&#x27;re in Python, you should embrace the syntax.

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

From Alex Martelli , a prominent Python expert [1]:<p>&gt; I&#x27;m one of those who prefers words to punctuation -- it&#x27;s one of the reasons I&#x27;ve picked Python over Perl, for example. &quot;Life is better without braces&quot; (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!-).<p>&gt; &quot;Paying&quot; some nanoseconds (for the purpose of using a clear, readable short word instead of braces, brackets and whatnots) is generally affordable (it&#x27;s mostly the cost of lookups into the built-ins&#x27; 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).<p>&gt; So, I&#x27;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;-).<p>[1] <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;2745292&#x2F;2285236" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;2745292&#x2F;2285236</a>

While it points at interesting questions about Python&#x27;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.<p>The performance of pure python code is orders of magnitude worse than non-interpreted languages, there&#x27;s no point trying to shave off 0.5% off a 5000% difference.

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