Hallo

Hier ist ne Seite mit 5 Tips:

http://www.developer.com/lang/perl/article.php/1554501


Nun bin ich mir aber nciht so sicher ob die auch stimmen... was meint ihr dazu?

Du kannst ein Hash nicht mit einem Array vergleichen. Es kommt stets auf die Situation an. Wenn du ein Array brauchst, nimm ein Array. Brauchst du ein Hash, nimm einen Hash. Wichtig ist nur, dass du vorher entscheidest, welche Datenstruktur für deine Aufgabe am besten geeignet ist. Benchmark.pm wird dir da sicherlich weiterhelfen --- andernfalls wirf mal einen Blick in perldoc perldata (perldoc perldata).
Wenn du es jedoch genau wissen willst: Arrays sind um etwa 20% schneller als Hashes. Sie sind nämlich nicht so komplex wie assoziative Arrays. Trotzdem kommt es auf den Gebrauch bzw. die Aufgabe an. Wenn du für eine Aufgabe Arrays verwendest, eigentlich Hashes aber besser passen, dann wird das ganze noch langsamer. Deshalb nutz immer das, was du für besser hälst. Deshalb stimmt die erste Aussage von dieser Seite auf jeden Fall nicht.\n\n

<!--EDIT|[E|B]|1084734042-->

Also bisher verwende ich immer so 5-8 Variablen mit

use vars($dbh, $sth,...)

würde es jetzt besser sein

use vars(@daten)
oder
use vars(%daten)

und dann halt hier zuweisen...?



Über die anderen Tips und so weiter, bitte ich natürlich auch um antworten.

Reducing Program Execution Time

1. stimmt nur in Ausnahmefaellen
2+3 ok
4. stimmt grundsaetzlich, aber

Quote

Grep and opendir can be used to get directory listings, and are often better than the large lists that would be returned from a glob

bringt nichts, weil readdir schon eine grosse Liste (i.d.R. groesser als glob) zurueckgibt; da besser mit readdir in skalarem context arbeiten (wobei grep nichts zu suchen hat...)

5. ist ok

6. perl hat keine garbage collection, sondern referenzzaehler...
undef %groessereDatenstruktur war bei perl5.6 ziemlich buggy und konnte eventuell recht viel laufzeit benoetigen (verglichen mit dem automatischen aufraeumen, wenn die datenstruktur einfach out-of-scope kommt)

I.d.R. ist aber Wartbarkeit und Lesbarkeit wichtiger als Geschwindigkeit, also sollte man sich dort nicht alles zu herzen nehmen... wenn man zu frueh zu optimieren versucht, optimiert man meistens falsch, und verbraet nur sinnlos entwicklungszeit, weil man erstens zu Beginn noch gar nicht weiss, wo wieviel Zeit verbraten wird, und zweitens durch die Optimierung der Code meistens unnoetig kompliziert wird...
Grundregel: Optimiere nicht. Wenn du unbedingt optimieren musst, optimiere spaeter...

Quote

1. stimmt nur in Ausnahmefaellen

Eben nicht! Siehe mein erster Post. Hashes sind nicht schneller.

ich meinte damit, dass in ausnahmefaellen hashes schneller sein koennen, aber in der Regel arrays schneller sind (ausser sie haben z.B. wenig elemente und sehr grosse loecher)

Ich finde den Tip 'Reguläre Ausdrücke sind langsam' seeeeehr gefährlich. Klar sind Reguläre Ausdrücke langsam - aber deutlich schneller als alle anderen Lösungen für gewisse Probleme. Und insbesondere sind Reguläre Ausdrücke weniger Fehleranfällig als so mancher substr-rumwurschtel-Code, den ich schon gesehen hab...

[quote=Ishka,16.05.2004, 23:48]substr-rumwurschtel-Code[/quote]
für die soll man ja eh pack und unpack nehmen! :)

[quote=Strat,16.May.2004, 23:01]6. perl hat keine garbage collection, sondern referenzzaehler...
undef %groessereDatenstruktur war bei perl5.6 ziemlich buggy und konnte eventuell recht viel laufzeit benoetigen (verglichen mit dem automatischen aufraeumen, wenn die datenstruktur einfach out-of-scope kommt)[/quote]
IMHO kann die Langsamkeit auch daher kommen, dass das verwendete malloc() fuer einige Einsatzgebiete eine schlechte Performance zeigt. Das malloc() von perl ist meistens schneller, geht aber auch verschwenderischer mit dem Speicher um.

[quote=ptk,17.05.2004, 10:03][quote=Strat,16.May.2004, 23:01]6. perl hat keine garbage collection, sondern referenzzaehler... [/quote][/quote]
Perl hat eine 'ausgezeichnete' Garbage Collection die sich u.a. auch mit dem Referenz-Zähler beschäftigt.