Bästa svaret
Kolla in det här pythonmeme
Svar
Några anledningar:
- Vid en viss punkt kan den mänskliga hjärnan inte uppfatta några förbättringar i hastighet. Om jag återimplementerar min Python-kod i C och den går 200 gånger snabbare, kommer användaren inte ens att märka om den ursprungliga koden redan sprang på 0,01 sekunder. Heck, de kommer förmodligen inte ens att märka om den ursprungliga koden bara kördes på 0,1 sekunder. Skillnaden mellan 0,1 sekunder och 0,0005 sekunder är faktiskt omärklig för de flesta. Även för de människor som faktiskt kan urskilja det känns det fortfarande helt obetydligt.
- Dess långsamhet beror i hög grad på hur du använder den. Det verkliga problemet är att många människor lider av problemet med för tidig optimering. Ja, Python är långsam, men chansen är att din kod inte är långsam på grund av Python. Den är långsam eftersom din kod använder fel datastrukturer och algoritmer för att lösa ett visst problem. Att använda ett sammanställt språk som C döljer bara problemet. Ja, det är snabbare, men det går bara snabbare vid en ineffektiv algoritm. Att använda rätt datastrukturer och algoritmer kommer att skala, ganska mycket oavsett vilket språk du implementerar dem på och oavsett hur mycket data du slutar hantera. snabbare språk kommer bara att skapa kortsiktiga vinster. En O (n!) – algoritm är fortfarande en O (n!) – algoritm, även om du implementerar den i C! Verkligt kunniga ingenjörer vet detta och kan göra applikationer som är mer än tillräckligt snabba och den skalas bra, oavsett implementeringsspråket, eftersom de använder rätt strukturer och algoritmer.
- Python har varit (och kommer sannolikt att fortsätta att vara) främst ett ”lim” -språk, det är mycket bra att ansluta programvaror som inte var ursprung Jag menade att arbeta direkt med varandra. Det är också bra att automatisera uppgifter som normalt skulle göras för hand. För dessa ändamål är det mer än tillräckligt snabbt, eftersom huvudarbetet ändå sker någon annanstans. För ”snabbare” språk som C är denna typ av limarbete så smärtsamt långsamt och felbenägen för kodning är knappast värt ansträngningen. Eventuella vinster i exekveringshastighet kompenseras mer än av den mängd slöseri med utvecklarens tid att få det att fungera. Det är en stor anledning till att det fortsätter att vara så populärt.
- Vissa flaskhalsar är helt enkelt utanför direktkontroll av implementeringsspråket. IO är vanligt. Jag har att göra med en applikation just nu där allt i Python är mer än tillräckligt snabbt. Det är först när vi träffar nätverket för att fråga databasen att saker och ting blir långsamma. Min profilering visar att även de långsammaste delarna av Python-koden är helt obetydliga jämfört med den tid som väntar på nätverket IO. Jag försöker nu hitta sätt att slå databasen mindre (cachelagring på klientsidan, undvika överflödiga sanityskontroller mot data etc.). Även om jag skrev ansökan i samlare skulle det fortfarande vara ett problem. Att lösa detta problem med Python är faktiskt snabbare och enklare eftersom det kommer med (mycket robusta) profilbibliotek i standardbiblioteket. Många ”snabba” sammanställda språk kommer traditionellt inte med detta ur lådan.
Moralen i berättelsen är: utvecklartiden trumfar maskintiden, nästan alltid. När det inte gör det håll, långsamhet är vanligtvis lokaliserbar för vissa flaskhalsar som enkelt kan optimeras till ett externt bibliotek eller tjänst. Tiderna när något verkligen inte kan optimeras till ett externt bibliotek eller tjänst är otroligt sällsynta. Som i, nästan obefintlig.
Ett undantag är om du vet från början att din ansökan kräver så nära realtidsprestanda som möjligt och majoriteten av koden kommer att vara datorcentrerad. Ett bra exempel är videospel eller DCC-applikationer. Dessa är bättre så nära realtid som möjligt, annars har du inte en användare bas att tala om.
Men såvida inte detta är fallet föredrar många utvecklare Pythons produktivitetsvinster, även om det bara är för prototyping.