7 ms·

"...who firmly believed that the terser your code, the faster it ran. The author crammed multiple side effects into a single expression, used ternary operators

"...who firmly believed that the terser your code, the faster it ran. The author crammed multiple side effects into a single expression, used ternary operators like they were going out of style, and generally believed that run time was proportional to the number of semicolons executed, and every variable killed a puppy." How does one go about countering that mentality in some rule of thumb fashion if at all possible? Could a disassembly illuminate identical push/pop operations on the memory stack as explicit intermediate variables would? Maybe a simple intermediate result expansion timing profile side by side the terse code's profile?

regularfry 9y ago
"Show me a benchmark."
- deleted 9y ago
  [deleted]
- falcolas 9y ago
  "Show me that this micro optimization is actually needed."
  - btschaegg 9y ago
    I like both of those and would like to add "Write a working implementation with a sane interface and unit tests first!" :-)
    - arethuza 9y ago
      "Make it work, make it right, make it fast".
      - Manozco 9y ago
        and then: make it distributed, make it serverless :D
        falcolas 9y ago
        At which point you get to re-do the "make it right, make it fast" steps. :D
jlangenauer 9y ago
"Here are our coding guidelines. If you don't like them, the door is over there."
- thesmallestcat 9y ago
  That doesn't work when you're handed a team of lazy idiots.
  - animal531 9y ago
    Or even someone who is fast and/or good. He just goes and does it whatever way he wants, then because it's done it just stays that way forever.
- rkangel 9y ago
  Yes, but what happens when the person in question wrote the guidelines and that's his attitude. Depressingly this is something that happens.
  - make3 9y ago
    Then it's you who takes said door and starts looking for a more sane place to work at
sawmurai 9y ago
If wouldn't even discuss this. If that the of code is that performance-critical just implement it in assembler.
- bjpbakker 9y ago
  IMO it does not necessarily need an assembler implementation, only if that is more clear. For performance enhancements where code readability suffers big time, I always want /proof/ by comparing the instructions (and some benchmarks help too).
Someone 9y ago
For some microcomputer basics that was true, as they implemented the 'find that line' part of goto and gosub by a linear search from the start of the program, skipping from line to line. Having fewer lines, or having the most often called routines at the start of the program would speed up programs, potentially a lot.
- taneq 9y ago
  Also various constrained environments (calculators and whatnot) where variables were significantly faster to access if they were declared locally than if they were global, or were faster if the name was shorter, etc. Not to mention the simple fact that, for old interpreted languages, the entire program text had to fit inside memory and so terseness literally saved you working memory.
  - nerdponx 9y ago
    In CPython, local function calls are still much faster than global function calls.
    - blattimwind 9y ago
      Similarly, in CPython function-local variables are faster to access than class or module attributes (with the usual bunch of exceptions you always have in Python). This probably applies to similar languages (like Ruby) as well.
  - supergreg 9y ago
    I've seen people recommend shorter names for MongoDB keys for faster querying.
  - warrenm 9y ago
    In C64 BASIC, iirc, only the first two characters of the [case-insensitive] variable name mattered - so "vacuum" and "vacation" were the same, since the 'real' variable name was "va"
mikekchar 9y ago
I once went to a code review in a very, very large (but now defunct) corporation. The author of the code did not allocation the memory they were writing into. There were 8 people at the code review. I could not convince a single person that writing into unallocated memory was a bad idea. "Allocating the memory would be slow", they countered. "And besides, we've tested it and it doesn't crash". Sometimes you can help people become better programmers. Sometimes you can't. Try not to stick around in positions where you don't have the ability/opportunity to make a positive contribution, is my best advice. But assuming that the person is willing to listen to you, all of the above seem like good approaches.
- fundabulousrIII 9y ago
  What the hell? Why didn't you just initialize the pointer to NULL and ask them to compile and test?
- phkahler 9y ago
  What memory were they using? How did they get a pointer to it? Perhaps there was reason to believe it would not be used but they had lost that reason to time. For example on many micro controllers you can have the linker reserve space for various things (mapping structures over memory mapped peripherals is common) so maybe the memory they were using was guaranteed to be available somehow. Or perhaps they really were clueless.
  - mikekchar 9y ago
    Keep in mind that this is more than 20 years ago, so my recollection of the details may be (probably are!) completely wrong. But this is what I recall. It was an embedded system with a proprietary language. The compiler didn't clear the variables when they were created (again, for performance reasons). For some crazy reason, the language allowed you to declare a pointer without initialising it. So what would happen is that the pointer would end up being whatever happened to be on the stack previously. The reason that it didn't crash in testing was because most of the code in the system was essentially copy and pasted from other parts of the system. As long as the previously run function had a pointer in the same location that happened to allocate some memory in the heap, and then deallocate it, this function would end up using the same memory and it would be fine. And this is exactly what happened in this case (because most of the functions had similar shapes and pointers were declared at the top of the stack frame). The main reason they were reluctant to change the code was because they had copied it from somewhere else and didn't understand how it worked. Because it didn't crash, they didn't want to touch it.
pdpi 9y ago
Introduce them to the concept of static single assignment form, and how it is an intermediate form that enables a tonne of downstream optimisations. Most of those "wasteful extra variables" would be introduced by the compiler anyway, so it's not a problem. Alternatively, just ask them to prove it. If it's faster, they can benchmark before and after, and prove that it's faster? No proof means you're full of shit. This is the Right Answer in that it's what you should be doing anyhow to avoid performance regressions, but it's way more combative and can cause problems within the team, so must be done tactfully.
- madflame991 9y ago
  > If it's faster, they can benchmark before and after That goes bad very fast. I've worked with someone who tried winning arguments with one-line microbenchmarks; They even tried to convince me that I should always use undefined over null in JS since one is faster than the other (forgot which). > Introduce them to the concept of static single assignment form I failed with this as well; some coders don't trust the compiler/runtime at all. I had people tell me that garbage collectors don't deal with cyclic dependencies or that "simple comparisons" (<, >, ==) are faster than "compound comparisons" (<=, >=).
  - nerdponx 9y ago
    To be fair, in R on my machine > and < seem to be faster than ==, at least for integers. But the difference is miniscule compared to the overhead of doing just about anything else.
  - arethuza 9y ago
    Craziest one I remember from my Java years (long long ago) was someone claiming that returning values by throwing exceptions and catching them to extract the return value was faster than simply returning the value.... This was wrong on a number of levels.
    - sgc 9y ago
      To be fair, they must have been full on bats--t insane.
maeln 9y ago
It's the programming equivalent of the people who try to put as many complex word in a sentence as possible to look clever. I met some people who were trying their best to make everything a oneliner because "shorter is better" or whatever reason they had at the time. The real reason I always saw was that it was making the code "hacker-like" (and completly unreadable) and they could brag about how clever they were.
- yen223 9y ago
  On the flip side, I met people who thought Python list comprehensions were "magic" and should be avoided at all costs
  - falcolas 9y ago
    I've met people who have created entire programs out of nested list comprehensions; "they're faster than for loops!". I don't avoid them myself, but you would be hard pressed to convince me to nest them, or do anything that takes more than one line to express.
    - whoopdedo 9y ago
      I think that's called Scheme.
  - btschaegg 9y ago
    Same goes e.g. for Linq. I know of people who would prefer screen-filling methods of multiple nested loops with throwaway datastructures and various checks sprinkled on top to a simple three-liner Linq expression. Funnily enough, their argument always seems to be "it's easier to read this, since I'm accustomed to for (x;y;z) if (foo ||(bar && baz)) lorem = ipsum; as a pattern."
    - dep_b 9y ago
      I can only imagine they got scared after seeing the SQL performance of Linq to SQL and all Linq to ORM based stuff after that.
JustSomeNobody 9y ago
You don't. You reward that developer by allowing them to persue other interests. Or stick them on writing one off tools that will never be customer facing.
ipnon 9y ago
Write a small program that uses a well-established compiler, then "optimize it" with all manner of clever tricks. Look at the assembly produced and you'll find nearly identical machine instructions with even more clever optimizations than you could have imagined.
mannykannot 9y ago
I think the problem is, to some degree, psychological. While the rational me knows there is very rarely any reason to prefer terseness over clarity of expression, the emotional me still gets a little thrill from one-liners and unconventional solutions (it can sometimes last right up until the point where I have to modify or debug code containing the damn things.) I think it is a pathological corner-case in an otherwise generally useful interest in, and appreciation of, innovative and economical problem solving.

regularfry 9y ago

"Show me a benchmark."

deleted 9y ago
[deleted]
falcolas 9y ago
"Show me that this micro optimization is actually needed."
- btschaegg 9y ago
  I like both of those and would like to add "Write a working implementation with a sane interface and unit tests first!" :-)
  - arethuza 9y ago
    "Make it work, make it right, make it fast".
    - Manozco 9y ago
      and then: make it distributed, make it serverless :D
      - falcolas 9y ago
        At which point you get to re-do the "make it right, make it fast" steps. :D

jlangenauer 9y ago

"Here are our coding guidelines. If you don't like them, the door is over there."

thesmallestcat 9y ago
That doesn't work when you're handed a team of lazy idiots.
- animal531 9y ago
  Or even someone who is fast and/or good. He just goes and does it whatever way he wants, then because it's done it just stays that way forever.
rkangel 9y ago
Yes, but what happens when the person in question wrote the guidelines and that's his attitude. Depressingly this is something that happens.
- make3 9y ago
  Then it's you who takes said door and starts looking for a more sane place to work at

sawmurai 9y ago

If wouldn't even discuss this. If that the of code is that performance-critical just implement it in assembler.

bjpbakker 9y ago
IMO it does not necessarily need an assembler implementation, only if that is more clear. For performance enhancements where code readability suffers big time, I always want /proof/ by comparing the instructions (and some benchmarks help too).

Someone 9y ago

For some microcomputer basics that was true, as they implemented the 'find that line' part of goto and gosub by a linear search from the start of the program, skipping from line to line. Having fewer lines, or having the most often called routines at the start of the program would speed up programs, potentially a lot.

taneq 9y ago
Also various constrained environments (calculators and whatnot) where variables were significantly faster to access if they were declared locally than if they were global, or were faster if the name was shorter, etc. Not to mention the simple fact that, for old interpreted languages, the entire program text had to fit inside memory and so terseness literally saved you working memory.
- nerdponx 9y ago
  In CPython, local function calls are still much faster than global function calls.
  - blattimwind 9y ago
    Similarly, in CPython function-local variables are faster to access than class or module attributes (with the usual bunch of exceptions you always have in Python). This probably applies to similar languages (like Ruby) as well.
- supergreg 9y ago
  I've seen people recommend shorter names for MongoDB keys for faster querying.
- warrenm 9y ago
  In C64 BASIC, iirc, only the first two characters of the [case-insensitive] variable name mattered - so "vacuum" and "vacation" were the same, since the 'real' variable name was "va"

mikekchar 9y ago

I once went to a code review in a very, very large (but now defunct) corporation. The author of the code did not allocation the memory they were writing into. There were 8 people at the code review. I could not convince a single person that writing into unallocated memory was a bad idea. "Allocating the memory would be slow", they countered. "And besides, we've tested it and it doesn't crash". Sometimes you can help people become better programmers. Sometimes you can't. Try not to stick around in positions where you don't have the ability/opportunity to make a positive contribution, is my best advice. But assuming that the person is willing to listen to you, all of the above seem like good approaches.

fundabulousrIII 9y ago
What the hell? Why didn't you just initialize the pointer to NULL and ask them to compile and test?
phkahler 9y ago
What memory were they using? How did they get a pointer to it? Perhaps there was reason to believe it would not be used but they had lost that reason to time. For example on many micro controllers you can have the linker reserve space for various things (mapping structures over memory mapped peripherals is common) so maybe the memory they were using was guaranteed to be available somehow. Or perhaps they really were clueless.
- mikekchar 9y ago
  Keep in mind that this is more than 20 years ago, so my recollection of the details may be (probably are!) completely wrong. But this is what I recall. It was an embedded system with a proprietary language. The compiler didn't clear the variables when they were created (again, for performance reasons). For some crazy reason, the language allowed you to declare a pointer without initialising it. So what would happen is that the pointer would end up being whatever happened to be on the stack previously. The reason that it didn't crash in testing was because most of the code in the system was essentially copy and pasted from other parts of the system. As long as the previously run function had a pointer in the same location that happened to allocate some memory in the heap, and then deallocate it, this function would end up using the same memory and it would be fine. And this is exactly what happened in this case (because most of the functions had similar shapes and pointers were declared at the top of the stack frame). The main reason they were reluctant to change the code was because they had copied it from somewhere else and didn't understand how it worked. Because it didn't crash, they didn't want to touch it.

pdpi 9y ago

Introduce them to the concept of static single assignment form, and how it is an intermediate form that enables a tonne of downstream optimisations. Most of those "wasteful extra variables" would be introduced by the compiler anyway, so it's not a problem. Alternatively, just ask them to prove it. If it's faster, they can benchmark before and after, and prove that it's faster? No proof means you're full of shit. This is the Right Answer in that it's what you should be doing anyhow to avoid performance regressions, but it's way more combative and can cause problems within the team, so must be done tactfully.

madflame991 9y ago
> If it's faster, they can benchmark before and after That goes bad very fast. I've worked with someone who tried winning arguments with one-line microbenchmarks; They even tried to convince me that I should always use undefined over null in JS since one is faster than the other (forgot which). > Introduce them to the concept of static single assignment form I failed with this as well; some coders don't trust the compiler/runtime at all. I had people tell me that garbage collectors don't deal with cyclic dependencies or that "simple comparisons" (<, >, ==) are faster than "compound comparisons" (<=, >=).
- nerdponx 9y ago
  To be fair, in R on my machine > and < seem to be faster than ==, at least for integers. But the difference is miniscule compared to the overhead of doing just about anything else.
- arethuza 9y ago
  Craziest one I remember from my Java years (long long ago) was someone claiming that returning values by throwing exceptions and catching them to extract the return value was faster than simply returning the value.... This was wrong on a number of levels.
  - sgc 9y ago
    To be fair, they must have been full on bats--t insane.

maeln 9y ago

It's the programming equivalent of the people who try to put as many complex word in a sentence as possible to look clever. I met some people who were trying their best to make everything a oneliner because "shorter is better" or whatever reason they had at the time. The real reason I always saw was that it was making the code "hacker-like" (and completly unreadable) and they could brag about how clever they were.

yen223 9y ago
On the flip side, I met people who thought Python list comprehensions were "magic" and should be avoided at all costs
- falcolas 9y ago
  I've met people who have created entire programs out of nested list comprehensions; "they're faster than for loops!". I don't avoid them myself, but you would be hard pressed to convince me to nest them, or do anything that takes more than one line to express.
  - whoopdedo 9y ago
    I think that's called Scheme.
- btschaegg 9y ago
  Same goes e.g. for Linq. I know of people who would prefer screen-filling methods of multiple nested loops with throwaway datastructures and various checks sprinkled on top to a simple three-liner Linq expression. Funnily enough, their argument always seems to be "it's easier to read this, since I'm accustomed to for (x;y;z) if (foo ||(bar && baz)) lorem = ipsum; as a pattern."
  - dep_b 9y ago
    I can only imagine they got scared after seeing the SQL performance of Linq to SQL and all Linq to ORM based stuff after that.

JustSomeNobody 9y ago

You don't. You reward that developer by allowing them to persue other interests. Or stick them on writing one off tools that will never be customer facing.

ipnon 9y ago

Write a small program that uses a well-established compiler, then "optimize it" with all manner of clever tricks. Look at the assembly produced and you'll find nearly identical machine instructions with even more clever optimizations than you could have imagined.

mannykannot 9y ago

I think the problem is, to some degree, psychological. While the rational me knows there is very rarely any reason to prefer terseness over clarity of expression, the emotional me still gets a little thrill from one-liners and unconventional solutions (it can sometimes last right up until the point where I have to modify or debug code containing the damn things.) I think it is a pathological corner-case in an otherwise generally useful interest in, and appreciation of, innovative and economical problem solving.