Anzeige:
Ergebnis 1 bis 10 von 10

Thema: Wie ihr euch Frust, Zeit & beschädigte Einrichtungsgegstände sparen könnt

  1. #1
    Registrierter Benutzer Avatar von ContainerDriver
    Registriert seit
    10.01.2003
    Beiträge
    418

    Wie ihr euch Frust, Zeit & beschädigte Einrichtungsgegstände sparen könnt

    Servus.
    Also, ich gebe hier jetzt mal zwei grundlegende Programmiertipps, die dermaßen logisch klingen, jedoch bei mir immer zu Problem führen (vgl. Titel, gerade eben schon wieder*):

    1. Wenn ihr euch dynamischen Speicher holt, dann fügt auch SOFORT IMMER den Befehl zum Freigeben von diesem in euer Programm ein.
    2. Wenn ihr ein Feld vergrößert, MÜSST ihr auch die Routine mitverändern, die das Feld initialisiert (Feldgrenzen!).

    Gruß, Florian

    * Ich mach einen Testlauf für mein Programm (das mogen 100% korrekt funktionieren muss): SIGSEGV.
    Ich wäre gerade eben fast durchgedreht :ugly:
    Dann ist mir aufgefallen (nach 1.5 h) das die SChleife, die eine Feld initialisiert falsch war (es wurden nicht alle Elemente initialisiert). Arg!
    Ein gebrechlich Wesen ist der X-Server.

  2. #2
    Registrierter Benutzer Avatar von fs111
    Registriert seit
    23.03.2002
    Beiträge
    594
    Ein Tipp, wie man sich sowas ganz erspart:

    1. Eine Sprache mit Garbage Collection benutzen.

    SCNR

    fs111

  3. #3
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Hmm

    x86-Assembler + Boehm-GC ;-)

  4. #4
    Registrierter Benutzer
    Registriert seit
    23.08.2004
    Beiträge
    24
    zum finden solcher probleme hilft

    valgrind --tool=memcheck --num-callers=958282 --leak-check=yes --show-reachable=yes -v binary

    http://valgrind.kde.org/
    Don't say things that hurt others, said pussycat.

  5. #5
    Registrierter Benutzer
    Registriert seit
    07.05.2007
    Beiträge
    656
    Zitat Zitat von florian hanisch Beitrag anzeigen
    ...
    2. Wenn ihr ein Feld vergrößert, MÜSST ihr auch die Routine mitverändern, die das Feld initialisiert (Feldgrenzen!).
    ...
    Dafür sorgt man, in dem man Felder (Arrays und sonstiges Geraffel) grundsätzlich über vordefinierte Konstanten initialisiert und Größen von structs usw. z. B. per sizeof abfragt:
    Code:
    /* C */
    #define ARR_SIZE 16
    ...
    char arr[ARR_SIZE];
    struct t_st {
      int x;
      char y;
      float z;
    } st;
    ...
    memset(arr, 0, sizeof arr);
    memset(st, 0, sizeof(struct t_st));
    
    int i;
    for (i = 0; i < ARR_SIZE; i++)
        arr[i] = '0' + i;
    ...
    Code:
    // Java
    private static final int ARR_SIZE = 16;
    ...
    String[] arr = new String[ARR_SIZE];
    for (int i = 0; i < ARR_SIZE; i++)
        arr[i] = "" + i;
    Jan

  6. #6
    Registrierter Benutzer
    Registriert seit
    18.03.2005
    Beiträge
    211
    1. Eine Sprache mit Garbage Collection benutzen.
    Steinigt Ihn !
    Ich mag schon selber bestimmen koennen, wann und wie mein speicher wieder freigegeben wird ... und MT sicherheit dann noch einhalten wird sicher nicht leichter :-)

    ALternativ halt c++ und seine moeglichkeiten nutzen anstatt c oder c style in c++ verwenden ...
    vectoren statt arrays, autoptr fuer quellen und senken

    Ciao ...

  7. #7
    Registrierter Benutzer Avatar von bischi
    Registriert seit
    10.04.2003
    Beiträge
    4.828
    Aber jetzt mal im Ernst: Programme werden immer grösser und komplexer. Was hast du da lieber: Etwas nicht freigegebener Speicher, den der GBC später freigibt oder bei jedem Durchlauf ein Speicherleck, das dir dann irgendwann das ganze RAM zumüllt?

    Ich meine: Klar kannst du die schnellsten Programme mit Assembler schreiben - nur wer macht das heute noch? (Ausnahmen bestätigen wie immer die Regel - es gibt sicherlich Beispiele, bei denen du die "lasche" Art des GBC nicht verkraftest...)

    MfG Bischi

    "There is an art, it says, or rather, a knack to flying. The knack lies in learning how to throw yourself at the ground and miss it" The hitchhiker's guide to the galaxy by Douglas Adams

    --> l2picfaq.pdf <-- www.n.ethz.ch/~dominikb/index.html LaTeX-Tutorial, LaTeX-Links, Java-Links,...

  8. #8
    Registrierter Benutzer
    Registriert seit
    07.05.2007
    Beiträge
    656
    Zitat Zitat von bischi Beitrag anzeigen
    Aber jetzt mal im Ernst: Programme werden immer grösser und komplexer. Was hast du da lieber: Etwas nicht freigegebener Speicher, den der GBC später freigibt oder bei jedem Durchlauf ein Speicherleck, das dir dann irgendwann das ganze RAM zumüllt?...
    Sehe ich auch so. Warum soll man dem Computer nicht überlassen, was er (meist) besser kann als die Fehlerquelle 80 cm vor dem Bildschirm? Garbage Collection ist eine rein mechanische Zählerei (wieviele Referenzen auf dieses Objekt gibt es noch?), sowas ist öde, langweilig und fehlerträchtig - und zählen kann ein Rechner i. a. besser als ich.

    Jan

  9. #9
    Registrierter Benutzer
    Registriert seit
    18.03.2005
    Beiträge
    211
    Aber jetzt mal im Ernst: Programme werden immer grösser und komplexer. Was hast du da lieber: Etwas nicht freigegebener Speicher, den der GBC später freigibt oder bei jedem Durchlauf ein Speicherleck, das dir dann irgendwann das ganze RAM zumüllt?
    Wenn man von anfang an aufpasst , das das zeug freigegeben wird ? Also wenn man sich bei der erzeugung gleich wieder gedanken ueber die zerstoerung macht ? Damit laesst sich das Problem IMHO gut haendeln ... Modulare programmierweisse, damit die projekte ned unuebersichtlich werden tun ihr uebriges ....

    OK, ich nutz gern und oft multithreading, da sind cow und gc soweieso kritisch zu betrachten. die machen dann meist mehr aufwand als wie sie nutzen bringen. Deshalb hab ich lieber einfachere Typen wo ich immer weiss, welchen status was grad hat ....

    Und GC in der Art wie JAVA sie verwendet, sind eher auch augenwischerei .... ob die GCs den SPeicher am Ende des Prozesses legetim wieder freigeben, oder ob die ordnungsgemaess implementierte c /c++ runtime bei proezessende die memoryleaks anmeckert und dann doch wieder freigibt, iss meist ned so der unterschied in der Praxis.

    Also wir ham hier Parser zu laufen, einige in c++ und mit xerces, und paar in java mit der xerces java impl (glaub ich zumindest), also die machen das selbe, nur wenn ich mir die verbreuchten ressourcen waehrend dem c++ parsen und dem java parsen anschaue (der laufzeitunterschied iss gar ned mal so gross) dann sind mir die ressourcen doch so viel wert das ich lieber auf GC's verzichte :-) Ob die Java Coder da nu richtige arbeit gemacht haben, kann ich leider ned beurteilen.
    Aber bei 15 GB xml file parsen, kann ich beim c++ parser nebenbei bequem browsen auf unseren Messrechnern, bei der java engine wird das browsen zur qual ....

    Ach ja, und es gibt eben nicht nur Desktop rechner ... sondern momentan "im kommen" sind auch kleine handliche geraete, wo eher auf stromverbrauch, temperaturfestigkeit als auf leistung und spreicher geachtet wird.

    Ciao ...
    Geändert von RHBaum (20-07-2007 um 12:30 Uhr)

  10. #10
    Registrierter Benutzer
    Registriert seit
    07.05.2007
    Beiträge
    656
    Zitat Zitat von RHBaum Beitrag anzeigen
    ...Und GC in der Art wie JAVA sie verwendet, sind eher auch augenwischerei .... ob die GCs den SPeicher am Ende des Prozesses legetim wieder freigeben, oder ob die ordnungsgemaess implementierte c /c++ runtime bei proezessende die memoryleaks anmeckert und dann doch wieder freigibt, iss meist ned so der unterschied in der Praxis....
    Der GC von Java gibt mitnichten Objekte nur am Prozessende wieder frei. Wie kommst Du darauf, dass das Augenwischerei ist? Er räumt nur den Speicher erst dann auf, wenn er meint, Zeit dazu zu haben - darum geht es bei GC aber nicht nur - es geht auch darum, dass jemand überwacht, welche Objekte ich wann und wo noch brauche (wenn ich z. B. Objekte an andere Objekte übergebe, die diese wiederum intern weiterführen usw. - wenn ich da jedesmal das Objekt kopiere, sehe ich noch schneller alt aus mit Speicherverbrauch).

    Und wenn Du meinst, dass es keinen Unterschied mache, wann Speicher freigegeben wird, dann hast Du wohl noch nie langlaufende Prozesse programmiert (Dienste / Dämons, ...)

    ...Also wir ham hier Parser zu laufen, einige in c++ und mit xerces, und paar in java mit der xerces java impl (glaub ich zumindest), also die machen das selbe, nur wenn ich mir die verbreuchten ressourcen waehrend dem c++ parsen und dem java parsen anschaue (der laufzeitunterschied iss gar ned mal so gross) dann sind mir die ressourcen doch so viel wert das ich lieber auf GC's verzichte :-) Ob die Java Coder da nu richtige arbeit gemacht haben, kann ich leider ned beurteilen.
    Aber bei 15 GB xml file parsen, kann ich beim c++ parser nebenbei bequem browsen auf unseren Messrechnern, bei der java engine wird das browsen zur qual ....
    Das ist dann wohl eher das Problem der falschen Parsing-Methode als der Programmierumgebung. Nutzt Du DOM? Schau Dich mal im Web um mit den Stichworten "xerces" und "big xml file". Mit DOM versucht nämlich Xerces, die ganze Struktur auf einmal in den Speicher zu kriegen.

    Ach ja, und es gibt eben nicht nur Desktop rechner ... sondern momentan "im kommen" sind auch kleine handliche geraete, wo eher auf stromverbrauch, temperaturfestigkeit als auf leistung und spreicher geachtet wird.

    Ciao ...
    Ja und? Dann brauchst Du keine saubere GC?

    Jan

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •