5 ms·

Rule #1 is bogus. If you're starting with a language that's 2-10x slower you're always going to be behind the curve. There's a reason C and fortran haven't gone

Rule #1 is bogus. If you're starting with a language that's 2-10x slower you're always going to be behind the curve. There's a reason C and fortran haven't gone anywhere.

OskarS 10y ago
You're not wrong, but in the real world it frequently happens that the choice of language is not the bottleneck. The bottlenecks are usually things like memory, network and file I/O, making the language you write in make very little difference.
- klodolph 10y ago
  Well... if memory is the bottleneck, and you use a language implementation where all the integers are heap-allocated, things are not looking good. I would say that choice of language can important if your bottlenecks are CPU, memory, or maximum latency.
squeaky-clean 10y ago
> If you're starting with a language that's 2-10x slower you're always going to be behind the curve. I got involved in a huge discussion about optimizing a web app recently. Things that were learned from the conversation? 1) It turns out moving more frequent cases to the top of an 'if-else' chain in JavaScript offers a greater speedup than I expected. 2) It doesn't matter if you shave 4ms off a request by optimizing your if-else chain if a little later in your code you make 27,000 database queries when you could have made 2. Knowing how to write a performant app will always be better than writing sloppy code in the fastest means possible.
- tomsmeding 10y ago
  27000 instead of 2 database queries would seem to be more than just a performance problem...
  - sokoloff 10y ago
    Yet it absolutely happens in Linq-to-SQL and other client-side join solutions. Within the last year, I've been in a post-mortem where this was the root cause of progressive slowness and eventual timeout (when the record set became progressively larger).
- overgard 10y ago
  That's kind of besides the point though, yes your bottleneck may not be CPU, but if it is, then language matters a lot
  - squeaky-clean 10y ago
    It's exactly the point. If you don't know what makes an app performant or not, moving to C++ is not going to magically make it any better if you're doing brute force operations everywhere. > yes your bottleneck may not be CPU, but if it is, then language matters a lot Even if your bottleneck is the CPU, it does not mean it's the programming language. A quicksort in python is faster than a "while not sorted randomly shuffle this list" in C++. Sure, moving to another language may be faster. But that is beside the point. The article even says "The programming language doesn’t matter as much as the programmers’ awareness about the implementation of that language and its libraries." So this whole discussion is under the assumption that a developer does not know what it takes to make an app fast. If you're using arrays in operations where you have to insert into the middle a lot, and never have to iterate over all of it sequentially, you probably should be using something like a linked list. Choosing the proper data structure (and learning why) should take priority over the faster language.
acomjean 10y ago
To some extent this is true. But built in datatypes that are performant are more likely to be used so thats an advantage some of the higher level languages have. Truly optimized C code will be faster than perl/python/php. But given the same problem the perl/pyhton/php programs will tend to use hashed data types (dictionaries in python, arrays is php) and end up with fast code. Sometimes faster than C code because the writing/using hashing in C is more difficult and its not always used.

Rule #1 is bogus. If you're starting with a language that's 2-10x slower you're always going to be behind the curve. There's a reason C and fortran haven't gone anywhere.

OskarS 10y ago

You're not wrong, but in the real world it frequently happens that the choice of language is not the bottleneck. The bottlenecks are usually things like memory, network and file I/O, making the language you write in make very little difference.

klodolph 10y ago
Well... if memory is the bottleneck, and you use a language implementation where all the integers are heap-allocated, things are not looking good. I would say that choice of language can important if your bottlenecks are CPU, memory, or maximum latency.

squeaky-clean 10y ago

> If you're starting with a language that's 2-10x slower you're always going to be behind the curve. I got involved in a huge discussion about optimizing a web app recently. Things that were learned from the conversation? 1) It turns out moving more frequent cases to the top of an 'if-else' chain in JavaScript offers a greater speedup than I expected. 2) It doesn't matter if you shave 4ms off a request by optimizing your if-else chain if a little later in your code you make 27,000 database queries when you could have made 2. Knowing how to write a performant app will always be better than writing sloppy code in the fastest means possible.

tomsmeding 10y ago
27000 instead of 2 database queries would seem to be more than just a performance problem...
- sokoloff 10y ago
  Yet it absolutely happens in Linq-to-SQL and other client-side join solutions. Within the last year, I've been in a post-mortem where this was the root cause of progressive slowness and eventual timeout (when the record set became progressively larger).
overgard 10y ago
That's kind of besides the point though, yes your bottleneck may not be CPU, but if it is, then language matters a lot
- squeaky-clean 10y ago
  It's exactly the point. If you don't know what makes an app performant or not, moving to C++ is not going to magically make it any better if you're doing brute force operations everywhere. > yes your bottleneck may not be CPU, but if it is, then language matters a lot Even if your bottleneck is the CPU, it does not mean it's the programming language. A quicksort in python is faster than a "while not sorted randomly shuffle this list" in C++. Sure, moving to another language may be faster. But that is beside the point. The article even says "The programming language doesn’t matter as much as the programmers’ awareness about the implementation of that language and its libraries." So this whole discussion is under the assumption that a developer does not know what it takes to make an app fast. If you're using arrays in operations where you have to insert into the middle a lot, and never have to iterate over all of it sequentially, you probably should be using something like a linked list. Choosing the proper data structure (and learning why) should take priority over the faster language.

acomjean 10y ago

To some extent this is true. But built in datatypes that are performant are more likely to be used so thats an advantage some of the higher level languages have. Truly optimized C code will be faster than perl/python/php. But given the same problem the perl/pyhton/php programs will tend to use hashed data types (dictionaries in python, arrays is php) and end up with fast code. Sometimes faster than C code because the writing/using hashing in C is more difficult and its not always used.