nö 8)

Quote

kabel@linux:~> perl -MO=Concise,-exec -e 'printf ("%.2f", 15)'
1 <0> enter
2 <;> nextstate(main 1 -e:1) v
3 <0> pushmark s
4 <$> const(SPECIAL Null)[t1] s
5 <$> const(SPECIAL Null)[t2] s
6 <@> prtf vK
7 <@> leave[t1] vKP/REFC
-e syntax OK
kabel@linux:~> perl -MO=Concise,-exec -e 'print sprintf ("%.2f", 15)'
1 <0> enter
2 <;> nextstate(main 1 -e:1) v
3 <0> pushmark s
4 <$> const(SPECIAL Null)[t2] s
5 <@> print vK
6 <@> leave[t1] vKP/REFC
-e syntax OK
kabel@linux:~>

das sprintf wird wegoptimiert ... sehr komisch ???

[quote=Dubu,22.09.2003, 23:03]s/print s//; ;)[/quote]
Huppsi!
Glatt printf vergessen! :D

@Crian

Ihr immer mit eurem Speicher! *g*

Du Jungspund! ;-)

Ich geb zu, die Zeiten, in denen man um jedes Bit gefeilscht hat sind vorbei (es sei denn man programmiert für eingebettete Systeme), aber das Wissen darum, wie mit dem Speicher umgegangen wird, sollte nicht völlig verlorengehen.

Man könnte sich sowieso mal fragen, warum der Bedarf an RAM und Festplattenplatz immer noch ungehindert weiter ansteigt... Das kann doch nicht nur an immer mehr Multimediaanwendungen liegen, oder? ???

Sicherlich nicht.
Aber soll ich jetzt zu jeder Funktion Benchmark Tests durchführen, wenn ich doh genau weiß - und ich weiß es genau -, dass mein PC 2 GHZ mit 256 DDR RAM besitzt? Wohl kaum. Die Zeiten sind vorbei, in denen um jedes Bit im Speicher gekämpft wird. Beispiel: Windows. Unter Windows komme ich mit meinen 256 MB RAM schlecht hin. Unter Linux hingegen werden die sehr gut ausgenutzt. Ich habe es (leider?) nicht mehr erlebt, dass man um jedes RAM Fitzelchen kämpft, tut mir also Leid, wenn ich euch nicht verstehe, wenn ihr darüber streitet, ob der Befehl nun in 0,00476 oder in 0,00486 Sekunden ausgeführt wird. ;)

Natürlich solltest Du nur die Stellen des Codes optimieren, die den Flaschenhals bilden.
Das ist eine der ersten Regeln des Optimierens.

Das nächstwichtige ist, ggf. den Algorithmus zu optimieren, bevor man den Code selbst optimiert.

Sobald Du mal mit embedded Systems zu tun bekommst oder einfach eine Funktion in einem großen Programm optimieren musst, die sehr sehr oft aufgerufen wird und deshalb den Flaschenhals bildet, wirst Du Dich freuen Dich daran zu erinnern, hier mal was davon gehört zu haben ;-)

P.S. Du hast einen 2 GHz PC mit nur 256 MB Ram? Urgs... meiner ist "nur" halb so schnell, hat aber fast doppelt soviel Ram...\n\n

<!--EDIT|Crian|1066654175-->

Du sollst perl ueberhaupt nicht optimieren; wenn du dennoch optimieren musst, optimiere spaeter :-))

das will eigentlich darauf hinaus, dass man so spaet wie moeglich zu optimieren anfangen soll, und zwar vom code her. Die Optimierung bezueglich der Algorithmen faellt da nicht rein, die kann man schon recht frueh machen (weil die eh normalerweise mehr bringt). Eine zu fruehe Optimierung der Programmiersprache geht naemlich meistens auf die Lesbarkeit, und somit auf die Wartbarkeit, und kostet im Endeffekt nur unnoetig Entwicklungszeit. Erst wenn das Programm von der Logik her alles perfekt macht, kann man, wenn noetig, mit der optimierung beginnen. Und wie?

Laufzeit:
1. die Stellen herausfinden, an denen sich eine Optimierung ueberhaupt lohnt (z.B. mit Devel::DProf. wenn eine Funktion nur einmal aufgerufen wird, lohnt sich da meistens ein Geschwindigkeitsgewinn von 50% nicht (ausser die Funktion braucht extrem lange). Wenn eine Funktion jedoch eine Million mal aufgerufen wird, lohnt sich haeufig sogar ein Gewinn von 1%.
2. Wenn man die Stellen lokalisiert hat, die sich auszahlen wuerden, kann man versuchen, da schnelleren Code zu produzieren, indem man bessere Kommandos verwendet (z.B. mit Benchmark ueberpruefen, ob er wirklich schneller ist (und dabei moeglichst wirklichkeitsnahe Daten verwenden, weil sonst der Benchmark nicht aussagekraeftig ist), oder Code nach C auslagert und einbindet

RAM:
Mehr RAM kaufen ist meistens billiger als Entwicklungszeit. Dabei sollte man jedoch darauf achten, dass bei den gaengigen 32-Bit-Betriebssysteme nur maximal 2GB RAM fuer Perl zur Verfuegung stehen, die durch die Speicherfragmentierung haeufig auf 1,4 GB oder so beschraenkt werden (=Out of Memory-Error bei Ueberschreitung). Deshalb gibt es da mehrere Wege, RAM zu sparen:
1. gegen die Speicherfragmentierung zu kaempfen: z.B. grosse Listen/Hashes schon zu presizen ($#liste = 100000)
2. gegen den Speicherbedarf selbst kaempfen: bessere Datenstrukturen verwenden, nur das in den Speicher laden, was benoetigt wird (geht meistens auf Kosten der Laufzeit), andere programmiersprache (geht meistens auf Kosten der Wartbarkeit und Entwicklungszeit)

256 MB RAM geht mit Win98/ME einigermaszen gut, nicht aber mit 2k/XP. Da sollten es schon 512 MB sein.
Ich ueberlege seit einiger Zeit hin und her, ob es nicht sinnvoll waere, auf 1024 MB upzugraden, weil meine Kiste unter Win2k mit 512MB RAM gelegentlich ins Swappen kommt....\n\n

<!--EDIT|Strat|1066655551-->

Ja, werd ich für meinen nächsten Rechner auch anpeilen... aber da ich mir den wohl erst 2005 leisten können :-/

Im Moment hab ich Win 98 drauf, das geht mit 4XY MB Ram gut (Athlon 1,2 GHz)

Der Rechner bei der Arbeit hat 512 MB Ram und 2,4 GHz unter Windows 2000 das geht eigentlich auch, obwohl ihm mehr Ram sicherlich auch nicht schaden würden...

Hab auch schon mit dem Gedanken gespielt. Werde mir sicherlich in der nächsten Zeit noch ein 256 MB RAM Steinchen kaufen. Die sind AFAIK nicht teuer. 40-50¤ glaube ich...

Klingt nach einer guten Investition.