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.