3 ms·
I think that's more of an indictment of how bad the concept of "production python" is.
by andrepd 6y ago
I think that's more of an indictment of how bad the concept of "production python" is.
- mateo411 6y agoI disagree with that. Production doesn't mean that the code runs fast, but that it is stable and reliable. There are use cases where you need a performant system that uses CPU really efficiently, in these cases Python is probably not the right tool.
- Dylan16807 6y agoLots of code doesn't run so often that it needs to be optimal. If you use proper data structures and algorithms then you'll avoid the real problems. The constant factor slowdown you get from language choice won't matter for the vast majority of lines of code.
- andrepd 6y agoThis is given as an excuse to write sloppy code and then we get the bloated mess that is modern software and the modern web. Plus python has many problems besides performance.
- Dylan16807 6y agoSloppy code would be using the wrong data structures and algorithms. Sloppy code would be optimizing nothing at all. If you write things with good big O performance, for almost all of your lines of code you're done. It will perform fine. Bloated messes don't come from writing a bunch of business logic in python instead of C, not while processors are this many orders of magnitude faster than they used to be. They comes from layers and layers of abstractions, or doing things completely the wrong way.
- BenjiWiebe 6y agoBut if you're processing 10's of thousands of records in an O(n) loop, it will still be 10's of thousands of times slower than processing a single record in that loop. i.e. having good big O still doesn't mean the code will be fast.
- Dylan16807 6y agoAre you saying this is a scenario where O(1) is possible? Then "good big O" is O(1). Code that is O(n) is a mistake. If you're saying the fastest method is O(n), then sure, no method can guarantee fast processing of the entire list. But that fact sure isn't python's fault!