6 ms·

"More readable code almost always means less efficient code." Can you give examples? I'm not sold that the "low hanging fruit" of readability improvement (empt

"More readable code almost always means less efficient code." Can you give examples? I'm not sold that the "low hanging fruit" of readability improvement (empty lines to break up "paragraphs", breaking up unintelligible one-liners into several lines, etc.) degrades performance. My intuition is that the compiler/interpreter ends up producing almost identical runtime code and therefore similar performance. Unless you mean more along the lines of expressivity (i.e Python and Ruby can get a lot done with fewer statements compared to C), but to me this effect is in a different category than readability.

wolfgang42 9y ago
Take the following code, which I had occasion to write this morning: foreach (var item in items) { if (items.Where(item2 => item.Upc == item2.Upc).Count() != 1) { item.Duplicate = true; } } This is the most readable and straightforward code I could come up with for the task; it's also not particularly efficient, since it does at least twice as many comparisons as necessary (more if there are actually duplicate items). To make it more efficient would require extra loops and manually indexing them to skip over comparisons that had already made; in this context I decided against this because the performance impact was minimal since there are other far less efficient portions of the code which would best be addressed first if the program turns out to be too slow.
- dozzie 9y ago
  Ever heard of these things called "hashes" a.k.a. "dictionaries"? They are magical boxes for elements that are indexed by name. You build such a magical box of seen elements while going through the checking loop and you get the time complexity of O(n) or O(n log(n)) instead of your current O(n^2), so it won't explode when you get more elements passing through the code. Note that this was conceived in just a few minutes of reading your code, deciphering syntax only remotely familiar, and figuring out what was it supposed to do, all with cold start (I haven't written much today yet). Something went wrong with your thought process.
  - wolfgang42 9y ago
    First, a small correction: the if statement in my original code can actually be written as the following, which is what I had in the actual code: if (items.Count(item2 => item.Upc == item2.Upc) != 1) With that correction out of the way, here's the code if I used a HashSet (you suggest 'a. k. a. "dictionaries"' but that is slower and I don't need the other half of the mapping which they would provide): var set = new HashSet<string>(); foreach (var item in items) { if (set.Contains(item.Upc)) { item.Duplicate = true; } else { set.Add(item.Upc); } } To my eye, this is less readable; in addition to having twice as many lines and an extra variable, it also takes extra work to figure out what it does; whereas my version does exactly what it says: if the UPC appears more than once, it marks the item as a duplicate. For a final comparison, here's an implementation of the extra loops and manual indexing I suggested: for (var i = 0; i < items.Count; i++) { for (var j = i + 1; j < items.Count; j++) { if (items[i].Upc != items[j].Upc) continue; items[i].Duplicate = true; items[j].Duplicate = true; break; } } This isn't significantly longer than the HashSet-based version, but it is even faster to run (I just benchmarked it) and also doesn't use an extra object which takes memory and needs to be managed and garbage-collected later. In conclusion, while I appreciate your suggestion for a possible alternative implementation, I do not appreciate your impugning of my abilities with the suggestion that "something went wrong with your thought process", and implying that I may not be aware of basic data structures.
    - dozzie 9y ago
      Dude, you're leaving O(n^2) landmines in your code and you're now justifying them by linecount and readability (actually more like familiarity with using sets and mappings). You have just proved my intuition about your abilities. Not to menion that: > you suggest 'a. k. a. "dictionaries"' but that is slower In what way you think mappings are different in implementation than sets that makes them slower? They only need to carry one more pointer, and you're already writing in a language quite detached from bare metal. One more thing, since you decided to "correct" yourself instead of letting the mistake slip: your "working" code is still wrong, unless something very weird happens in the data (but then calling it more readable this way is fundamentally wrong).

wolfgang42 9y ago

Take the following code, which I had occasion to write this morning: foreach (var item in items) { if (items.Where(item2 => item.Upc == item2.Upc).Count() != 1) { item.Duplicate = true; } } This is the most readable and straightforward code I could come up with for the task; it's also not particularly efficient, since it does at least twice as many comparisons as necessary (more if there are actually duplicate items). To make it more efficient would require extra loops and manually indexing them to skip over comparisons that had already made; in this context I decided against this because the performance impact was minimal since there are other far less efficient portions of the code which would best be addressed first if the program turns out to be too slow.

dozzie 9y ago
Ever heard of these things called "hashes" a.k.a. "dictionaries"? They are magical boxes for elements that are indexed by name. You build such a magical box of seen elements while going through the checking loop and you get the time complexity of O(n) or O(n log(n)) instead of your current O(n^2), so it won't explode when you get more elements passing through the code. Note that this was conceived in just a few minutes of reading your code, deciphering syntax only remotely familiar, and figuring out what was it supposed to do, all with cold start (I haven't written much today yet). Something went wrong with your thought process.
- wolfgang42 9y ago
  First, a small correction: the if statement in my original code can actually be written as the following, which is what I had in the actual code: if (items.Count(item2 => item.Upc == item2.Upc) != 1) With that correction out of the way, here's the code if I used a HashSet (you suggest 'a. k. a. "dictionaries"' but that is slower and I don't need the other half of the mapping which they would provide): var set = new HashSet<string>(); foreach (var item in items) { if (set.Contains(item.Upc)) { item.Duplicate = true; } else { set.Add(item.Upc); } } To my eye, this is less readable; in addition to having twice as many lines and an extra variable, it also takes extra work to figure out what it does; whereas my version does exactly what it says: if the UPC appears more than once, it marks the item as a duplicate. For a final comparison, here's an implementation of the extra loops and manual indexing I suggested: for (var i = 0; i < items.Count; i++) { for (var j = i + 1; j < items.Count; j++) { if (items[i].Upc != items[j].Upc) continue; items[i].Duplicate = true; items[j].Duplicate = true; break; } } This isn't significantly longer than the HashSet-based version, but it is even faster to run (I just benchmarked it) and also doesn't use an extra object which takes memory and needs to be managed and garbage-collected later. In conclusion, while I appreciate your suggestion for a possible alternative implementation, I do not appreciate your impugning of my abilities with the suggestion that "something went wrong with your thought process", and implying that I may not be aware of basic data structures.
  - dozzie 9y ago
    Dude, you're leaving O(n^2) landmines in your code and you're now justifying them by linecount and readability (actually more like familiarity with using sets and mappings). You have just proved my intuition about your abilities. Not to menion that: > you suggest 'a. k. a. "dictionaries"' but that is slower In what way you think mappings are different in implementation than sets that makes them slower? They only need to carry one more pointer, and you're already writing in a language quite detached from bare metal. One more thing, since you decided to "correct" yourself instead of letting the mistake slip: your "working" code is still wrong, unless something very weird happens in the data (but then calling it more readable this way is fundamentally wrong).