> And I hate when people use efficiency when they mean speed.
Except they're usually right. "Efficiency" is not just a measure of algorithmic complexity. Something is more efficient if you are able to do more of a desired activity at the cost of fewer resources. The resource in question varies.
Yes, one often in computer science focuses on algorithmic complexity as the resource to be economized on. But time and power are also perfectly reasonable resources to have in mind. In fact, they are the resource that most audiences will naturally assume when they see the word "efficient" standing along, without further explanation.
I think GP is probably wrong to criticize as well -- making code more efficient [or, if you insist, fast] makes it easier to support more users that it could support otherwise. Is the ease with which a system can support an additional user not the very definition of the word "scalability"?
Of course, there are more powerful, and more specialized techniques for improving scalability, but that doesn't mean the author is wrong to suggest that speed improves scalability.
Sometimes it does. For example if you write a simple O(n) for loop in Python, then convert it to Cython, then compile it, the compiler may replace the for loop by an equivalent O(1) algorithm. I use this to surprise students when benchmarking Cython code for teaching purposes in my SageMath course.
If it's just a matter of speeding up a tight loop, I find numba performs admirably and it's a lot more convenient than Cython.
When you need to wrap some c code, or use high-level data structures (that cython handles beautifully with STL integration) that's when it makes sense to drop to Cython.
I'll give you "the complexity of your algorithm" likely doesn't change, but how that algorithm is processed is usually more efficient when compiled through C, rather than running through a Python interpreter, if only because of how it's running.
I agree it is faster by running it through compiled C code.
Saying "my code is more efficient than your code" might be acceptable, but saying "my code is efficient" drives me mad when it is used as a synonym for "my code is fast". Take a look at [1] and the note that this is not about optimization. Efficient algorithms are usually algorithms with close to optimal time or space complexitiy.
Except they're usually right. "Efficiency" is not just a measure of algorithmic complexity. Something is more efficient if you are able to do more of a desired activity at the cost of fewer resources. The resource in question varies.
Yes, one often in computer science focuses on algorithmic complexity as the resource to be economized on. But time and power are also perfectly reasonable resources to have in mind. In fact, they are the resource that most audiences will naturally assume when they see the word "efficient" standing along, without further explanation.
I think GP is probably wrong to criticize as well -- making code more efficient [or, if you insist, fast] makes it easier to support more users that it could support otherwise. Is the ease with which a system can support an additional user not the very definition of the word "scalability"?
Of course, there are more powerful, and more specialized techniques for improving scalability, but that doesn't mean the author is wrong to suggest that speed improves scalability.