5 ms·

I met someone who was specifically using `dict()` instead of `{}` because, he told me, the CPython parser was much slower on the later than on the former and th

by thu 12y ago

I met someone who was specifically using `dict()` instead of `{}` because, he told me, the CPython parser was much slower on the later than on the former and that it was noticeable on larger code base. (That being said I think using Python should be about writing maintainable code, not about micro-optimization. I don't claim the purpose of that site is to push you to use those micro-optimizations, even if the title seems to suggest so. Including the disassembly makes for a nice visualization.)

chriswarbo 12y ago
> I met someone who was specifically using `dict()` instead of `{}` because, he told me, the CPython parser was much slower on the later than on the former and that it was noticeable on larger code base. I've been told by code reviewers to use micro-optimisations like this before. My default reply is "I think this way is faster, since the shorter code results in fewer cache misses. I'd be happy to change it if you show me some benchmarks." Of course, the cache may or may not affect anything; the point is to burst their philosophical bubble with an example of why measurements are needed. There's also the good old fashioned "If we cared that much about performance, we wouldn't be using the branching logic of a templating system in an interpreted language."
- Spidler 12y ago
  Optimize for readability. Optimize for maintainance. Optimize for consistency. Once those three are done, you can optimize for performance.
  - jqm 12y ago
    But, you can also possibly habitually change a few things in your initial coding syntax that produces less computational effort to begin with.... I thought it was a good article.
    - marcosdumay 12y ago
      If those few things do not break redability, maintaince, consistence, or correctness, why not? So, first you get good enough on the language to know you are not breaking those. Then you don't adopt micro-optimizations because you are already good enough on it to know what they'll break.
    - chriswarbo 12y ago
      1) We don't know which one takes more computational effort, hence the need for realistic benchmarks with decent confidence intervals. 2) If benchmarks show one style to be slightly faster than another, then I will take note. I've already noted that these benchmarks have no associated statistical information; they're just numbers quoted to an arbitrary precision. 3) If I ever find myself needing such slight increases in speed, it's probably a sign that there's a looming disaster, since it means that a) there's a bottleneck in the program, b) I can't improve the algorithm, c) porting that section to native code hasn't been enough. If it's a case of death by a thousand papercuts, where slight slow-downs throughout an application are actually making it unusable, then I'll roll up my sleeves and patch the interpreter/compiler (this is easier in self-hosting languages, but doable in all).
      - jqm 12y ago
        No need to get all carried away talking about rewriting compilers or pulling out statistical confidence intervals... If a certain style has a slight performance improvement, and this can be manifested, and that style is equally as readable and maintainable, there is simply no reason not to adopt it as habit. That's all I'm saying.
    - Spidler 12y ago
      Why? Because most of the ones they show is that a global lookup is more costly than a local one. Something that may -very- well change quickly. dict() slower than {}, and so on...
- jlarocco 12y ago
  Meh. My opinion is that it's easier to just change the code. The reality is there's probably no noticeable difference, and if it's important enough to them that they marked it on a code review they might actually try the benchmark, and then you're just wasting everybody's time.
  - chriswarbo 12y ago
    It depends on the team I guess, but in my situation all changes had to be checked in to git, rebased against the live branch, pass code review, have the pass logged against that git commit, have paperwork filed in triplicate indicating the pass, etc. so it was a PITA to restart that process for such insignificant changes. Much easier to argue with the reviewer; plus, if it stops them doing it again in the future, all the better ;) It's funny that even with all of this process in place, things broke routinely when trivial syntax errors would slip through. There were no automated tests or monitoring systems, of course. It seemed like the process was to keep developers in check rather than ensure a working product; I think someone watched Superman 3 or Office Space and got paranoid. Needless to say, I'm not there anymore ;)

by thu 12y ago

chriswarbo 12y ago

> I met someone who was specifically using `dict()` instead of `{}` because, he told me, the CPython parser was much slower on the later than on the former and that it was noticeable on larger code base. I've been told by code reviewers to use micro-optimisations like this before. My default reply is "I think this way is faster, since the shorter code results in fewer cache misses. I'd be happy to change it if you show me some benchmarks." Of course, the cache may or may not affect anything; the point is to burst their philosophical bubble with an example of why measurements are needed. There's also the good old fashioned "If we cared that much about performance, we wouldn't be using the branching logic of a templating system in an interpreted language."

Spidler 12y ago
Optimize for readability. Optimize for maintainance. Optimize for consistency. Once those three are done, you can optimize for performance.
- jqm 12y ago
  But, you can also possibly habitually change a few things in your initial coding syntax that produces less computational effort to begin with.... I thought it was a good article.
  - marcosdumay 12y ago
    If those few things do not break redability, maintaince, consistence, or correctness, why not? So, first you get good enough on the language to know you are not breaking those. Then you don't adopt micro-optimizations because you are already good enough on it to know what they'll break.
  - chriswarbo 12y ago
    1) We don't know which one takes more computational effort, hence the need for realistic benchmarks with decent confidence intervals. 2) If benchmarks show one style to be slightly faster than another, then I will take note. I've already noted that these benchmarks have no associated statistical information; they're just numbers quoted to an arbitrary precision. 3) If I ever find myself needing such slight increases in speed, it's probably a sign that there's a looming disaster, since it means that a) there's a bottleneck in the program, b) I can't improve the algorithm, c) porting that section to native code hasn't been enough. If it's a case of death by a thousand papercuts, where slight slow-downs throughout an application are actually making it unusable, then I'll roll up my sleeves and patch the interpreter/compiler (this is easier in self-hosting languages, but doable in all).
    - jqm 12y ago
      No need to get all carried away talking about rewriting compilers or pulling out statistical confidence intervals... If a certain style has a slight performance improvement, and this can be manifested, and that style is equally as readable and maintainable, there is simply no reason not to adopt it as habit. That's all I'm saying.
  - Spidler 12y ago
    Why? Because most of the ones they show is that a global lookup is more costly than a local one. Something that may -very- well change quickly. dict() slower than {}, and so on...
jlarocco 12y ago
Meh. My opinion is that it's easier to just change the code. The reality is there's probably no noticeable difference, and if it's important enough to them that they marked it on a code review they might actually try the benchmark, and then you're just wasting everybody's time.
- chriswarbo 12y ago
  It depends on the team I guess, but in my situation all changes had to be checked in to git, rebased against the live branch, pass code review, have the pass logged against that git commit, have paperwork filed in triplicate indicating the pass, etc. so it was a PITA to restart that process for such insignificant changes. Much easier to argue with the reviewer; plus, if it stops them doing it again in the future, all the better ;) It's funny that even with all of this process in place, things broke routinely when trivial syntax errors would slip through. There were no automated tests or monitoring systems, of course. It seemed like the process was to keep developers in check rather than ensure a working product; I think someone watched Superman 3 or Office Space and got paranoid. Needless to say, I'm not there anymore ;)