Man muss sich wohl bei Aussagen, wie "Mein C-CSV-Parser ist schneller als mein Python-CSV-Parser" die Libraries ansehen. Wäre mir ziemlich sicher, dass da deutlich andere Sachen passieren.
Wie schon erwähnt kommt man mit Python in vielen Sachen nicht an C ran, aber so pauschal muss man auch vorsichtig sein. Mitunter called man ja in einem Python-Programm auch C, da kann dann der Call was langsames sein.
Aber es sind eine Reihe anderer Punkte, die den wirklich großen Performance-Unterschied machen in vielen Systemen. Neben den Garbage-Collector, der je nachdem wie man programmiert das Programm mitunter häufig zum Stillstand bringt gibt's noch so Sachen, wie dass man Dictionaries und Listen mit Structs und tyypsierten Arrays vergleicht, was natürlich Humbug ist. Wenn ich in ein dict, wo mir für jeden Key ein "kryptographischer" Hash mit einer Struktur, die direkt addressierbar im Speicher liegt und auf die ich direkt zugreife vergleiche, dann kann man sich ja schon denken, dass es einen Unterschied beim Zugriff darauf gibt. "Gib mir mal den Speicher" und "Rechne mir mal den Hash für folgenden Key aus, such mit dann in er Hashtabelle den passenden Key und nutze die Referenz dort um die Daten im Speicher zu finden" sind halt Welten an Unterschied.
Ganz generell, muss man aber eine Sprache, bzw. den Interpreter/Compiler kennen um das richtige zu tun, auch wissen was im Hintergrund passiert. Oft kann es auch schon helfen so grundsätzliche Dinge zu wissen, wie, ob ich jetzt Referenzen nutze oder Kopien erstelle, oder wie teuer meine Function Calls sind, ob die nette rekursive Funktion nicht doch mit einem einfach For-Loop deutlich schneller wäre, etc.
Ressourcen zu sparen ist auch ziemlich generisch. Welche Ressourcen? Memory, CPU-Zeit oder etwas ganz anderes?
Generische Bücher dazu zu finden ist schwierig, vor allem weil man da mitunter nicht das bekommt was man im Alltag braucht. Also wenn man sich zum Beispiel ein Buch mit vielen tollen Algorithmen schnappt, dann wird man schnell feststellen, dass die ja ohnehin von der Sprache bzw. der Library, die man nutzt verwendet werden.
Was man damit aber vielleicht bekommt ist ein Gefühl dafür wie Aufwendig ein Algorithmus/ein Programm ist, was Ressourcen angeht, auch was teuer ist (auch wenn man das am besten profiled/benchmarked).
Man kann's auch anders angehen und wenn man interpretierte Sprachen nutzt einfach mal Pypy oder LuaJIT nutzen. Das ist dann mitunter ein gelöstes Problem.
Im Endeffekt geht's dann aber auch Schnell in Richtung Erfahrung, weil auch wenn man sich mit all diesen Dingen beschäftigt hat, ist es gut zu wissen, wo man anfängt, was potentielle Quick-Wins sind, auch wenn man mit einem Profiler drüber gegangen ist und weiß, wo viel Zeit genutzt wird, heißt das noch Lange nicht, dass man weiß was die beste Möglichkeit das Problem anzugehen ist. Falscher Datentyp, falsches Lib, falscher Algorithmus, liegt's an meinem Code, kann ich die teure Funktion weniger oft callen, kann ich mir was sparen, wenn ich mir etwas merke oder gibt es ganz generell einen Trade-Off den ich machen kann, bzw. sollte ich das ganze Problem anders angehen oder bin ich gar ohnehin schon am Limit?
Ein Tipp wäre es ein Performance-Problem, das man schon hat, warum man vielleicht das ganze Thema angehen will herzunehmen und zu nutzen um genau zu verstehen warum es besteht und dieses Problem dann auf unterschiedliche Arten zu lösen und zu verstehen warum es da wieder die jeweiligen Unterschiede gibt. Das bringt sehr viel. Danach versteht man die Sprache (bzw. deren Compiler oder Interpreter) besser, versteht, ob Garbage Collection einen Einfluss hat und auch den Algorithmus und die Datenstrukturen, die man nutzt bzw. deren Implementierung.
Der Grund warum Erfahrung da wichtig ist, ist dass je nachdem was man will sehr, sehr unterschiedliche Dinge die Lösung des Problems sein können. Wenn's anders wäre hätten wir wahrscheinlich schon irgendwelche Tools die uns die Arbeit magisch abnehmen würden und sagen würden, was man zu tun hat. Teilweise gibt es so etwas sogar, aber meist auch noch gute Gründe einen Menschen drüber blicken zu lassen.
