ContactViewer aus GoPal3.0 unter GoPal5.0 nutzen

    Man kann sowas von zwei Seiten angehen, Deinen Weg und oder meinen, wo ich schaue, was vor dem Aufruf frei ist und nach dem Beenden (der Bedarf für den CV selber interessiert mich ja nicht). Das Delta ist dann der Anteil, der nicht freigegeben wurde, je weniger, umso besser.

    Auch das sehe ich anders (oder falsch?). Die Differenz (dein Delta) zwischen Ptogamm geöffnet und wieder geschlossen wird durch zweierlei verursacht: Einmal durch den Speicherverbrauch für das Programm selbst, zum anderen durch die Daten für das Program (z.B. contacts.db beim CV).


    Nach dem Schließen wird entweder der gesamte Speicher freigegeben, (was definitiv das Beste wäre) oder nur ein Teil, z.B. Daten und einige Programmteile.
    Wenn dann noch Speicheranteile belegt sind, dann ist das nicht optimal programmiert, aber durchaus denkbar und leider üblich (schlechtes Speichermanagement, welches den Speicher nicht wieder freigibt. Kann aber auch absichtlich für ein schnelleres erneutes Starten des Programms bewußt so programmiert sein).


    Ich denke, daß der geringste Speicherverbrauch nach dem Schließen wichtiger ist als der Speicherbedarf durch das Programm CV samt seinen Daten, weil für das Navigieren (mit POIs, Favoriten und Schnickschnack wie Track-Aufzeichnung) der RAM ganz sicher manchmal knapp wird.


    Damit wären wir wieder bei dem leidigen Thema RAM und sonstiges Menory...


    ---


    Jetzt habe ich drei Tabellen aus verschiedenen Versuchsserien vor mir, weiß aber nicht, ob ich sie und wie hierher reinladen soll oder kann.

    Habe Deinen Text jetzt noch einmal gelesen und merke, daß wir ja doch auf der selben Welle sind. Also Delta klein ist wichtig und Dein Delta ist zwischen vorher und nach dem Schließen...

    Genau, wer was an Speicher verbraucht, interessiert mich nicht (solange es die 32MB-Grenze nicht überschreitet bzw. an der 'Gesamtmenge' kratzt), daher schaue ich nur nach dem Delta vorher/nachher.


    Eine vernünftige GarbageCollection (das Wiederfreigeben der benötigten Ressourcen) obliegt bei C++ dem Programmierer (in Java macht's die VM) -> Destruktoren (daraus ergibt sich logischerweise auch keine Konsequenz für die Konstruktoren "schnellerer Start").


    Der Speicherbedarf zur Laufzeit des CV ist letztlich egal, solange nicht beides CV + GoPal) parallel im RAM liegt.


    Eine optimale Situation -> kein Speicherverbrauch, wird man bei etwas größeren Programmen fast nie erreichen, selbst das Windows ist da verschwenderisch.


    Ich hoffe, dass war etwas verständlich in diese Problematik eingeführt.

    Deine 'Einführung' war prägnant und die Auffrischung eines schon irgendwann vernommenen Fachworts (Garbage Collection) ein Genuß.


    Offen bleibt nur, was man als Wiederfreigabe (nicht mehr) benötigter Ressourcen versteht. Ein (ganz sicher nur laienhaftes und analoges) Beispiel: OOo braucht beim Start relativ lange, nach Schließung und erneutem Aufruf gehts rapide. Da bleibt doch ein ganz sicher Speicher fressendes Teil zurück, dessen Notwendigkeit man aus verschiedener Sicht unterschiedlich bezüglich Notwendigkeit bewerten könnte.
    Beim PDA mit knappen Ressourcen jedenfalls würde man Freigabe vorziehen, beim RiesenPC sieht man lieber die Geschwindigkeit beim erneuten Starten...


    Gruß

    Zitat von quotsi

    Beispiel: OOo braucht beim Start relativ lange, nach Schließung und erneutem Aufruf gehts rapide. Da bleibt doch ein ganz sicher Speicher fressendes Teil zurück, dessen Notwendigkeit man aus verschiedener Sicht unterschiedlich bezüglich Notwendigkeit bewerten könnte.


    Dafür ist aber der Cache verantwortlich.

  • Monika

    Hat das Label [GoPal 5.x] hinzugefügt.