I just can not understand why this is happening. If we look at the source code of CPython , then you can see that both entities are equivalent and are represented as an array. This means that the call to dict() must not distinguish between speed and {} .

As an experiment (in order to make sure that it is the same entity) I tried to do this:

 class Some({}.__class__): def hello(self): {}.__init__(self) print('Hi!') some = Some() some['one'] = 1 print(some['one']) some.hello() 

Output to console:

 1 Hi! 

What should be expected.

Measured the speed of operations is not the most reliable way, but rather revealing:

 >>> from timeit import timeit >>> timeit("{}") 0.058351269999548094 >>> timeit("dict()") 0.12427372599995579 

Could you tell why {} is 2.5 times faster than dict() ?

  • I do not see the speed test {} / dict () here. How did you determine this difference? Did you warm up the virtual machine before the benchmark? - etki
  • @Etki unfortunately I don’t know how to use the benchmark ... - faoxis
  • It does not make sense to measure the performance of broken code. Remove class Some ... an example — he has nothing to do with it. Use the word "dictionary" rather than "array" in Python for similar objects - jfs
  • @jfs is not an example for a speed test, but in order to make sure that it is the same entity - faoxis
  • @faoxis you look at the title of the question. The question is about speed. Your example proves nothing — it's broken - jfs

2 answers 2

Faster because {} is a syntax built into python.

And when you use dict() , the interpreter must also run through the namespace to find this dict .

But in general, when they write on python, they usually do not pay much attention to speed, since in this case the speed at which the program is created is more important. If speed is categorical , it is better to turn your attention to the " C " language, either as a module creation for python near a bottleneck, or as an independent program.

  • Most likely LOAD_GLOBAL in bytecode is exactly what you are talking about. - A1essandro
  • Well, what is global, in your opinion? - Mr Fix

Indeed, creating an empty dictionary using a special syntax is faster than by name:

 >>> import timeit >>> "%.2f \xb5s" % min(timeit.repeat("dict()")) '0.45 µs' >>> "%.2f \xb5s" % min(timeit.repeat("{}")) '0.28 µs' 

You can see bytecode:

 >>> import dis >>> dis.dis(lambda: {}) 1 0 BUILD_MAP 0 3 RETURN_VALUE >>> dis.dis(lambda: dict()) 1 0 LOAD_GLOBAL 0 (dict) 3 CALL_FUNCTION 0 (0 positional, 0 keyword pair) 6 RETURN_VALUE 

If dict name is not overridden, then the same objects are returned in both cases:

 >>> type({}) <class 'dict'> >>> type(dict()) <class 'dict'> >>> {} == dict() True 

In real code, unless the profiler told you that it is the creation of an empty dictionary that has a bottleneck, you should not choose between these constructions for the speed of completion of this test.

  • one
    "one should not choose between these constructions for the speed of completion of this test", but why? If {} is faster, it would be more logical to remove all dict() and write {} ? - faoxis
  • @faoxis show an example of real code where create an empty dictionary is a bottleneck. I almost always use {} to create an empty dictionary, but this has nothing to do with the speed of the construct. Do not try to engage in micro-optimizations and especially in Python. - jfs
  • one
    See, you have some virtual machine that performs the python-key bytecode. We do not know what is inside of it, what optimization it can do or not do, what it can cache, where it can sag. But we can say for sure that a) if the resulting machine code is identical, then the first calls may subside due to the initialization of additional components (it’s not a fact that initialization has ended by the time the code is executed and does not go in parallel), b) the machine has the right to optimize calls on the go, if he sees a hot code, c) other host processes may interrupt the machine - etki
  • one
    I can equally well blame everyone who I don’t like about the effect of dunning-kruger. I do not say that the results of tests show untruth, I say that they do not confirm anything, except for one particular case; I do not understand how this can be denied. - etki
  • one