var char[256] - Grundsätzliche Frage zur Speicherverwaltung
-
In meinem geplanten Programm wird sehr viel mit Strings gearbeitet, vor allem in Form von Char-Arrays innerhalb von Funktionen. Nach dem Verlassen der Funktionen ist der Speicher wieder frei. Ich überlege also: Wie groß kann der String maximal werden, gehe sicherheitshalber auf etwa das Doppelte und lege fest: char[64] oder char[128] usw. Dabei tauchen nun zwei Fragen auf, über die ich mir bisher keine Gedanken gemacht habe:
1. Warum wähle ich instinktiv Zahlen der Zweierpotenz-Reihe? Ein char[500] kommt mir irgendwie "krumm" vor, char[512] ist sympathischer. Ist das nur Angewohnheit, also sowas wie "Programmierästhetik", oder sollte man wirklich besser auf Zweierpotenzen zurückgreifen?
2. Auch die Länge wirft Fragen auf. Wenn die lokalen Char-Arrays ohnehin wieder freigegeben werden, ergibt es dann überhaupt einen Sinn, sie so klein wie möglich zu machen? Mehr noch: Könnte es sogar vorteilhaft sein, mit einheitlichen, großzügigen Pufferlängen wie z.B. char[1024] zu arbeiten, weil dann die freigegebenen Speicherbereiche besser und schneller neu belegt werden können?
Mag sein, dass das alles keine Rolle spielt, aber wenn ich daran denke, dass einige der Funktionen mehrere tausend mal aufgerufen werden, möchte ich doch möglichst optimal vorgehen.
Gruß,
Reinhard
-
@1: Ich tippe mal auf Gewohnheit - Programmierer denken in Zweierpotenzen
@2: Speicherplatz ist begrenzt - und wenn du sehr viele Arrays anlegst, die du nie brauchst, ist das einfach nur Verschwendung.
-
so lange nicht fuer uCs programmiert wird, kann man ruhig verschwenderisch sein. optimierung erst wenn alles funktioniert.
-
Also feste Rahmengrößen sind doch schon eher etwas für die Geschichtsbücher. Ein gut durchdachtes Programm ist dynamisch! Empfehlenswert ist vielleicht die Arbeit mit calloc(sizeof *x)
-
Hyper_gscheiter schrieb:
Also feste Rahmengrößen sind doch schon eher etwas für die Geschichtsbücher. Ein gut durchdachtes Programm ist dynamisch! Empfehlenswert ist vielleicht die Arbeit mit calloc(sizeof *x)
Traurig, dass hier immer vom normalen 0815-x86 ausgegangen wird...
-
TactX schrieb:
Hyper_gscheiter schrieb:
Also feste Rahmengrößen sind doch schon eher etwas für die Geschichtsbücher. Ein gut durchdachtes Programm ist dynamisch! Empfehlenswert ist vielleicht die Arbeit mit calloc(sizeof *x)
Traurig, dass hier immer vom normalen 0815-x86 ausgegangen wird...
ich fühle mit dir...
-
traurig, dass hier immer von mikrokontrollern ausgegangen wird...
ein bisschen schmerz kann man sich doch sparen, indem man weniger knauserig mit speicher und prozessorleistung umgeht. die zeiten von mainframes und prozessorzeit gegen geld sind vorbei.
allerdings stimmts schon. wer programmiert denn noch C? kernelprogrammierer, embedded-leute und wer nen flaschenhals zu bewaeltigen hat. dafuer ist C doch gedacht: performance. performance fuer einen haufen code, fuer dessen erstellung man zeit braucht, die sich manche menschen noch nehmen.
-
c.rackwitz schrieb:
traurig, dass hier immer von mikrokontrollern ausgegangen wird...
das ist eins der hauptanwendungsgebiete von C...
c.rackwitz schrieb:
allerdings stimmts schon. wer programmiert denn noch C? kernelprogrammierer, embedded-leute und wer nen flaschenhals zu bewaeltigen hat. dafuer ist C doch gedacht: performance....
in embedded-foren gibt es öfters mal kleinkriege zwischen C und assembler-fans, wer den meisten speed rausholt usw. (so wie hier immer C++ gegen Java).
die assembler-fraktion hat bisher immer gewonnen
-
Was ist '0815-x86' ?
PS.: Ich bin noch neu in der (C) Programmierung
-
08/15 muss nicht erklärt werden, glaub ich.
x86 ist eine Prozessorarchitektur. Hauptsächlich die alten 32bit-Intel und AMDs sind Exemplare dieser Architektur.
-
was mit 0185 gemeint ist, sollte jeder wissen
die Archtitektur x86 ist die im Desktop PC (eigentlich in IBM kopatiblen) PC die Prozessorarchitktur, die im Einsatz kommt. D.h. ein normaler Rechner, den man bei Media Markt kauft, ist ein x86 Rechner.
Siehe auch http://de.wikipedia.org/wiki/X86-Prozessoredit: heute bin ich zu langsam
-
Als Verursacher dieses Threads muss ich mich doch noch mal einmischen. Das Programm, von dem ich sprach, ist überaus zeitkritisch, also kommt es stark auf gute Performance an.
In dem Zusammenhang: Ich finde nicht, dass man so Aspekte wie Speicherbedarf und Performance ganz außer Acht lassen sollte, auch wenn die Hardware rund 1000 mal so leistungsfähig ist wie noch vor 15 Jahren. Es zeigt sich doch immer wieder, dass die Programmierer die Hardware in die Knie zwingen können. Eklatantes Beispiel: der MS Flight Simulator unter Windows.
U.a. beschäftige ich mich zur Zeit intensiv mit dem Spielprogramm Tuxracer (C-Programm). Die alte Version 0.61 läuft auf meinem mittelmäßigen Rechner (800 MHz, Riva TNT - 3D-Grafikkarte der ersten (!) Generation) immerhin mit 50 - 90 fps. Da ist noch Spielraum vorhanden, der auch dringend gebraucht wird. Der Nachfolger ppracer, der in C++ programmiert ist, schafft gerade knapp 20 fps, ohne dass Funktionalität dazugekommen ist. Die letzte Version von ppracer, kurz bevor das Programm starb, brach mit weniger als 5 fps ein.
Dabei gibt es in Tuxracer keine genialen Algorithmen, die für die Performance sorgen, sondern es wurde einfach auf die Performance geachtet. So werden z.B. nicht unnötig Daten herumgeschaufelt, sondern konsequent mit Zeigern übergeben. Optimale Performance lässt sich m.E. nicht nur durch großartige Algorithmen, sondern auch und vor allem durch viele Optimierungen im Kleinen erreichen.
Ich jedenfalls ärgere mich, wenn die Programmierer vor ihren Superkisten sitzen und voraussetzen, dass bei den Anwendern ebenfalls nichts unter 3 GHz und 1 GB läuft. Und dann gibt ja noch Programmierer, die gedankenlos mit Speicher und Prozesserlast um sich werfen, bei denen sich aber die Nackenhaare sträuben, wenn mal eine Library statisch gelinkt werden soll. Manchmal habe ich Probleme, die Leute zu verstehen.
Sorry, ich musste das mal los werden.
Reinhard
-
erin schrieb:
Optimale Performance lässt sich m.E. nicht nur durch großartige Algorithmen, sondern auch und vor allem durch viele Optimierungen im Kleinen erreichen.
das stimmt nicht.
du kannst dir 'nen wolf optimieren, wenn du einen schlechten algorithmus verwendest hilft das nichts.
da muss nur mal einer kommen und den besseren (passenden) algo einsetzen und es läuft 10 mal schneller ohne optimierung.
-
erin:
es gibt auch programme, da kommt es auf performance GARNICHT an. die laufen keine 100 ms und sind dann fertig.
bei nem flight simulator oder tuxracer lohnt sich optimierung, weils da um frameraten geht. das sollte dir doch klar sein.
dir sollte auch klar sein, dass es auch programme gibt, die keine spiele sind und auch sonst keine performance verlangen.
es geht darum, zu wissen WANN optimierung was bringt und wann nicht.
es geht darum, sich die arbeit nicht GRUNDLOS zu machen.
-
Ja, danke für die Erklärung!