4 ms·

Is there any comprehensive overview of why python is slow in the first place? There seems to be opportunities for small optimizations, but is that the only pla

Is there any comprehensive overview of why python is slow in the first place? There seems to be opportunities for small optimizations, but is that the only place where the slowness is? A few years ago I tried to find out what investigations had been done on the speed of bytecode generation and there was basically nothing. No one could even suggest how long bytecode generation took, only that "it's really slow". Isn't the common wisdom to measure, then optimize, not the other way around?

mjburgess 6y ago
It has nothing to do with it being interpreted (this is a common misidentified issue with dynamic langs). The fundamental issue is that python is a pointer machine: everything requires a dynamic lookup in memory. Eg., x = [1, 2, 3] len(x) Here `x` is an actual string in memory which is a key in a locals() dictionary which holds values. (cf. with C where it is just a memory address). Likewise the list is a list of pointers (not a sequential array). And its heterogenous, ie., the contents can be of any type. Likewise `len` is a string into a dictionary of functions which has to be looked up. etc. The whole thing is many levels of indirection. Applying an operation to a value (eg., even x + y) requires jumping around the memory of the machine many times. This is necessary, in general, to deliver on the dynamic lang. features python provides. Julia solves some of these issues by using static type information to ditch this dynamic behaviour. My suspicion is that python can follow a similar path (eg., above, x should be compiled to a static homogenous array of ints).
- jashmatthews 6y ago
  Local variables in CPython are stored in the stack frame and accessed via LOAD_FAST and STORE_FAST without doing anything with x as a string or a hash table: http://stupidpythonideas.blogspot.com/2015/12/how-lookup-works.html http://stupidpythonideas.blogspot.com/2015/12/how-lookup-wor...
  - mjburgess 6y ago
    My claim there was only that it was reified in memory, not that in the case of loading x, you had to use it. Though it is worth noting that you dont. In general the point stands, the reason for slowness is indirection & reification. (Not sure why i'm downvoted).
    - jashmatthews 6y ago
      The locals dict is lazily created from the locals in the stack frame. No dict there unless you use it. The article I linked to before has a really good explanation of this. len() only causes one dictionary lookup and then it's cached. > This is necessary, in general, to deliver on the dynamic lang. features python provides. It's the most obvious way to implement these features of dynamic languages but not at all necessary. https://www.infoworld.com/article/2074780/avoiding-hash-lookups-in-a-ruby-implementation.html https://www.infoworld.com/article/2074780/avoiding-hash-look... https://bibliography.selflanguage.org/_static/pics.pdf https://bibliography.selflanguage.org/_static/pics.pdf

mjburgess 6y ago

It has nothing to do with it being interpreted (this is a common misidentified issue with dynamic langs). The fundamental issue is that python is a pointer machine: everything requires a dynamic lookup in memory. Eg., x = [1, 2, 3] len(x) Here `x` is an actual string in memory which is a key in a locals() dictionary which holds values. (cf. with C where it is just a memory address). Likewise the list is a list of pointers (not a sequential array). And its heterogenous, ie., the contents can be of any type. Likewise `len` is a string into a dictionary of functions which has to be looked up. etc. The whole thing is many levels of indirection. Applying an operation to a value (eg., even x + y) requires jumping around the memory of the machine many times. This is necessary, in general, to deliver on the dynamic lang. features python provides. Julia solves some of these issues by using static type information to ditch this dynamic behaviour. My suspicion is that python can follow a similar path (eg., above, x should be compiled to a static homogenous array of ints).

jashmatthews 6y ago
Local variables in CPython are stored in the stack frame and accessed via LOAD_FAST and STORE_FAST without doing anything with x as a string or a hash table: http://stupidpythonideas.blogspot.com/2015/12/how-lookup-works.html http://stupidpythonideas.blogspot.com/2015/12/how-lookup-wor...
- mjburgess 6y ago
  My claim there was only that it was reified in memory, not that in the case of loading x, you had to use it. Though it is worth noting that you dont. In general the point stands, the reason for slowness is indirection & reification. (Not sure why i'm downvoted).
  - jashmatthews 6y ago
    The locals dict is lazily created from the locals in the stack frame. No dict there unless you use it. The article I linked to before has a really good explanation of this. len() only causes one dictionary lookup and then it's cached. > This is necessary, in general, to deliver on the dynamic lang. features python provides. It's the most obvious way to implement these features of dynamic languages but not at all necessary. https://www.infoworld.com/article/2074780/avoiding-hash-lookups-in-a-ruby-implementation.html https://www.infoworld.com/article/2074780/avoiding-hash-look... https://bibliography.selflanguage.org/_static/pics.pdf https://bibliography.selflanguage.org/_static/pics.pdf