Speicher wird voll und Programm wird langsamer bis zum Stillstand / Lisp
Andreas Kraus 04. Aug. 2020, 13:58

Hallo zusammen,
ich habe folgende LISP-Konstuktion:

Code:
(foreach dwgname files_list
    (vla-open (setq dbx (k_get_interface_object))
      dwgname
    )
;;; mach was in der Datei
    (k_erfassung_work dbx)
    (k_rp004_work dbx)
    (k_elt_002 "Erfassen" dbx)
    (vla-saveas dbx dwgname)
    (not (vl-catch-all-error-p
  (vl-catch-all-apply
    'vlax-release-object
    (list DBX) ;_DBX-Verknüfung wieder freigeben
  )
)
    )
    (gc)
    (princ)
  )

Das Problem dabei ist dass bei jeder Datei die Speicherauslastung (im Task Manager) hochläuft und das LISP etwas langsamer wird bis es einfach stehenbleibt und ich ACAD per Taskmanager killen muss. Mehr als 4-5 Dateien nacheinander gehen nicht. Dann muss ich ACAD schließen, neu starten und mit den Dateien weitermachen. Die aktuelle Datei schließen bringt auch nichts, ACAD muss komplett zu. Nervt ganz schön.

Ich hab mich noch nicht mit Speicherbedarf usw. beschäftigt weil ich bisher kein Problem damit hatte.
Hab mal zum Ausprobieren (gc) ins Programm geschrieben ... hat nix gebracht.
Kann mir mal jemand einen kräftigen Tritt in die richtige Richtung geben ?

joern bosse 08. Aug. 2020, 15:11

Hallo Andreas,
ich würde zumindestens die Rückgabe der Funktion VL-CATCH-ALL-ERROR-P auswerten:

Code:

(if (vl-catch-all-error-p
        (vl-catch-all-apply
          'vlax-release-object
          (list DBX) ;_DBX-Verknüfung wieder freigeben
        )
      )
    (alert "Fehler bei Release")
  )

Desweiteren würde ich alle Funktionen auskommentieren und dann immer nur eine testen, um zu prüfen, ob diese Deinen Speicher zumüllen.

Andreas Kraus 09. Aug. 2020, 12:13

Danke Jörn,
hab gestern noch dran rumprobiert.
Die Funktion (k_rp004_work dbx) ermittelt für alle Blockeinfügungen Raumpolygone und schreibt Daten in die Objekte.
Wird dann für Massenermittlung, Raumbuch, Schemapläne, usw. verwendet.

Folgende Erkenntnisse:
- Es liegt NICHT an ODBX
- es liegt ziemlich eindeutig daran dass die Daten in die Objekte geschrieben werden.
- ich verwende dafür erweiterte Elementdaten, muss noch testen ob das mit Attributen auch passieren würde.
- das reine Ermitteln der Daten macht nichts, erst das Schreiben der Daten erhöht der Speicherbedarf.
- Wenn (k_rp004_work dbx) nicht ausgeführt wird oder dort das Schreiben in die Objekte auskommentiert ist, läuft alles super.

Meine Funktion um Daten in Objekte zu schreiben ist ziemlich komplex weil hier beliebige Daten in beliebige Objekte geschrieben werden können. Ich reduziere das mal auf EEDs und schau mal was passiert.

Andreas Kraus 09. Aug. 2020, 15:50

Hab auch noch z.B. das hier gefunden:
https://ww3.cad.de/foren/ubb/Forum54/HTML/003875.shtml#000004

Ist zwar von 2003 aber kann ja sein dass sich da nix getan hat 

joern bosse 10. Aug. 2020, 07:40

Hallo Andreas,
wie speicherst Du die erweiterten Elementdaten an die Objekte, mit ENTMOD und Gruppencode -3 oder über vla-SetXData?

Ich hatte vor ein paar Jahren auch schon mal ein Problem mit Xdaten innerhalb eines DBX-Objektes gehabt, dann habe ich anstelle ENTMOD vla-SetXdata verwendet und der Spuk war vorbei. Leider weiß ich nicht mehr, wodrin in meinem Fall das Problem lag, aber für Dich wäre es vielleicht ein Versuch wert, es mit einer anderen Variante zu probieren.
Viel Glück.

Andreas Kraus 10. Aug. 2020, 17:19

Hm ... also ich verwende grade vla-SetXData und wollte jetzt mal die ENTMOD-Methode versuchen.
Is ja lustig 
Hatte aber heute noch keine Zeit. Die Arbeit, die Arbeit.

Andreas Kraus 10. Aug. 2020, 21:35

Ich glaube es ist _UNDO.
Habs grade ausprobiert, teste es aber nochmal morgen in der Firma auf der Maschine wo es die Probleme gab.

Wenn ich _UNDO ausschalte bleibt hier der Speicherbedarf wo er ist. Schwankt wärend der Ausführung etwas aber so im Großen Ganzen tut sich nix.
Wär ja fast zu einfach um gleich drauf zu kommen 

Andreas Kraus 23. Sep. 2020, 08:32

Hatte endlich wieder Zeit zum Suchen 
Habs gefunden 
Oh ... wie blöd war das denn   

Hab eigene INI-Dateien die ich so aufgebaut habe dass ich die mit LOAD laden kann.
Dabei wird auch gecheckt ob sich was aktualisiert hat.
Das ist mir in eine Schleife geraten und ich hatte bei jedem Zugriff auf die INI-Daten auch einen LOAD-Befehl um die Datei zu checken.
Bei JEDER Änderung von Attributen, Parameter, EEDs.
Hunderte von LOADs

Das macht den Speicher voll und den Rechner langsam.

Jetz hab ich ein LOAD am Anfang und dann ist Ruhe.

Ich frage mich aber ob man irgendwie verhindern kann dass, wenn mit LOAD immer wieder dasselbe geladen wird, der Speicher immer weiter vollläuft und ACAD ausgebremst wird.
Wenn da jemand was weiß ... ich lerne gerne dazu 

Andreas Kraus 23. Sep. 2020, 08:54

Update zu meiner Antwort 

Es ist nicht LOAD ... es ist vlax-ldata-put 

Jetzt weiß ich was ich umbauen muss