[64-bit] more headroom for memory-leaks

Summary

I don’t need no 64-bit, neither 4D-standalone nor 4D Client. We’ll never have that much data to process. These days I was wondering, why my 4D-standalone occupied 8 GB of the available 16 GB of RAM. Turned out, my code was leaking memory.

Ich brauche keine 64-Bit, weder in 4D Einzelplatz noch im 4D Client. Wann werde ich jemals soviel Daten haben, daß sich 64-Bit rechnen? Dieser Tage wunderte ich mich, daß 4D Developer 8 GB der verfügbaren 16 GB brauchte. Es stellte sich heraus, ich hatte mir ein memory-leak eingebaut.


Ich arbeitete an Postleitzahl-Karten. In der Überprüfung der Qualität der Daten nutzte ich die 3-stelligen Zonen zur Kontrolle. Diese sind hinreichend detailreich und man bekommt relativ schnell mit, wo es hakt. Wenn es irgend geht, setze ich die V15 64-Bit ein. Die zeichnet schnell und ich komme voran. 3-stellige PLZ-Bereiche zeichnen ± so schnell wie hier im GIF die Karte wechselt.

Dreistellige PLZ als Karte
Dreistellige PLZ als Karte

Ich war über die 0-er, 1-er Postleitzahlen bis irgendwo in Baden-Württemberg gelandet (7-er) als 4D merklich langsamer wurde. In der Aktivitätsanzeige entdeckte ich: 8 GB für 4D, die restlichen 8 GB teilten sich die anderen zwei Dutzend Anwendungen. Oh, das sollte so nicht sein. In der Tat: SVGs werden erzeugt und der SVG-Baum im Speicher gehalten. Vor der nächsten Karte jedoch wird der vorherige SVG-Baum nicht gelöscht. Ich hatte mir ein memory-leak eingebaut. Tja, 64-Bit schützt nicht vor memory-leaks, es dauert nur länger bis der Speicher knapp wird.


These days I was working on ZIP-maps. To check the quality of the data I created maps for the first 3 digits. Those maps show the details, making it easy to see when something is wrong. Nowadays if possible, I use the 64-bit version of V15. This is a fast one and I’m getting through quicker. Those 3-digit maps draw ± as fast as the map is changing in this GIF.

Dreistellige PLZ als Karte
3-digit zip-area as map

I had worked through the 0-zone, 1-zone through all the zones up until somewhere in Baden-Württemberg (7-zone), where 4D got really slow. The Activity Monitor showed me: 8 GB for 4D, while the other 8 GB where used by some 20 other apps. Oh, there is something wrong. Indeed: SVGs got created and the SVG-tree was kept in memory. Drawing the next map didn’t free up the previous used one. That’s what I call a nice memory-leak. With 64-bit memory-leaks still happen, it only takes longer until they hurt.

Ein Kommentar:

  1. Tatsächlich ist 4D seit Version 11 mit Memory-Leaks an allen Ecken und Enden geplagt und 4D ist nicht fähig das Problem in den Griff zu bekommen.
    Besonders dramatisch ist das am Server, einige Anwendungen muss man periodisch neu starten weil sie sonst im Crash enden.
    Wir haben sogar Fälle, wo normale 4D Querys am Client nachweislich auf dem Server Memory-Leaks verursachen !

    Echt schade um eine einst stabile Plattform.

Kommentare geschlossen.