Only if you're sure that the particular algorithm you're working on is the bottleneck.
One particularly common performance pessimization is replacing an algorithm with one that has better big-O performance but a worse constant factor, and doing so where the particular O is much smaller than the number of times the function is called. People learn that hashmaps are O(1) while red-black trees are O(log N) and linear search is O(N), so they'll default to using a hashmap for a lookup table, even if the lookup table has 10 items but the keys are ~500 byte strings. (I'm guilty of this one myself, but at least I measured and fixed it.)
Then they'll call this lookup in a loop 5000 times.
Using Python or another rapid-prototyping language can be a good idea here if you take the time to profile and identify the bottlenecks, but very frequently you end up shipping it, throwing hardware at it, and then wondering why you're spending hundreds of thousands of dollars on AWS bills. Plus, a really big problem with many common Python architectures is that they use pure Python libraries & frameworks even on the critical path. (Big offenders here include using BeautifulSoup in your 1B-page web analysis or Django on your million-user website.)
Something I made the mistake of saying in interviews for a bit, but now save for beers, is that often the 'hardest part' of the project is cleaning up all of these constant factor bits. They're thankless. They're everywhere, and at some point your flame chart looks pretty damned flat. There are no big wins anymore. It's fighting for inches.
(really the 'hardest thing' about software is all of the things that are true but few believes are important. Dropping the Big O can be proven empirically)
One particularly common performance pessimization is replacing an algorithm with one that has better big-O performance but a worse constant factor, and doing so where the particular O is much smaller than the number of times the function is called. People learn that hashmaps are O(1) while red-black trees are O(log N) and linear search is O(N), so they'll default to using a hashmap for a lookup table, even if the lookup table has 10 items but the keys are ~500 byte strings. (I'm guilty of this one myself, but at least I measured and fixed it.) Then they'll call this lookup in a loop 5000 times.
Using Python or another rapid-prototyping language can be a good idea here if you take the time to profile and identify the bottlenecks, but very frequently you end up shipping it, throwing hardware at it, and then wondering why you're spending hundreds of thousands of dollars on AWS bills. Plus, a really big problem with many common Python architectures is that they use pure Python libraries & frameworks even on the critical path. (Big offenders here include using BeautifulSoup in your 1B-page web analysis or Django on your million-user website.)