6 ms·
There's probably something to this statement. there was a great article I saw on HN about a year ago that was talking about this (wish I'd bookmarked it). Crux
by milesvp 12y ago
There's probably something to this statement. there was a great article I saw on HN about a year ago that was talking about this (wish I'd bookmarked it). Crux of it was he looked at idiomatic python, saw all the hash lookups that entailed and said if you wrote C like that, it'd be slow as hell too. he then proceeded to speed up an algorithm to near C speeds by removing structures relying on these lookups. Was quit amazing to see.
Keep in mind that in current computer architectures memory requests are very slow. And any data structure that randomizes memory access means that you have a good chance of a cache miss and now have to hit even slower ram.
- mcguire 12y agoPractically every operation in Python starts with a hashtable lookup. Global and local environments are hashtables, modules are hashtables, objects are hashtables. Eventually you get down to C, which is usually very good---the hashtable implementation in particular---but for a lot of Python code the extra indirections are expensive. That's also why it is hard to optimize. In this particular case, I don't think it's the problem, though. Just something to keep in mind.
- berdario 12y agoYou're probably thinking of this: https://speakerdeck.com/alex/why-python-ruby-and-javascript-are-slow https://speakerdeck.com/alex/why-python-ruby-and-javascript-...
- kyllo 12y agoThis is also relevant, someone implemented early-binding virtual method tables in Python and benchmarked the performance speedup: http://legacy.python.org/workshops/1998-11/proceedings/papers/lowis/lowis.html http://legacy.python.org/workshops/1998-11/proceedings/paper...