---

Hallo zusammen,

muß auch mal wieder eine Frage stellen:

Ich habe ein Programm, das Blöcke in eine Zeichnung einträgt.
Aber: Es dauert ewig bis er damit fertig ist.

Zu den Grundvoraussetzungen:
DWG mit ca. 400 vordefinierten Blöcken
Blöcke werden ohne Attribute aus einer im Speicher befindlichen Liste
mittels der .InsertBlock Methode eingetragen.
Bei 70 000 einzutragenden Punkte ist AutoCAD inzwischen 3 Stunden beschäftigt.
Ein Versuch ohne BlockRefObj.Update bringt minimale Verbesserung.

Wie macht Ihr das bei großen Datenmengen?
Bin am überlegen ob es nicht sinnvoller wäre anstatt der .InsertBlock Methode direkt ModellSpace.Items zu ergänzen.

Gibt es da schon Erfahrungswerte ?

Wäre schön eine Antwort zu bekommen.

Danke,
Klaus

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi Klaus,

für solche Fälle stehe ich grundsätzlich auf dotNET, da fahren wir in einer Applikation (Raumplanung) je Darstellung generieren (ein Großteil davon Blöcke) samt Berechnungsfunktionen wie Dissolve, ... in der Regel > 100.000 Objekte und das in < 2min.

Mit VBA hast Du spätestens mit 64bit-Version von AutoCAD einen zusätzlichen 'Verlangsamungsfaktor' von 10, damit fällt für mich VBA (ausser für schnelle, ganz kleine, nur wenige male verwendete Makros) raus.

Ich nehme auch an, dass Du wohl schon bei den Blockdefinitionen nachgesehen hast, dass diese sauber sind und nicht unnötigen Balast mitschleppen.

'ModelSpace.Items.Add' ==> geht so nicht, oder?

Es kann Sinn machen, den Undo-Modus zu deaktivieren, dann schreibt er keine Undo-Informationen raus, das ist sicher schon mal einiges an Performance, fraglich aber, ob das der Workflow erlaubt. ('_undo' '_c' '_off' / 'zurück' 'steuern' 'nichts')

Nicht probiert, aber möglich: statt
ThisDrawing.ModelSpace.InsertBlock
probier mal
ThisDrawing.Database.ModelSpace.InsertBlock

Wenn Du mir Zeichnung mit ein paar typischen Blockdefintionen + Codeschnippsel vom Einfügen uploadest, dann hab ich vielleicht noch mehr Ideen.

- alfred -

---

DFKDWG_Vorlage.zip

Hallo Alfred,

Danke für die Antwort, Du warst ja schnell ..

Codeschnipsel:

Code:

---

Sub TextAuftrag()
    Dim TextObj As AcadText
    Dim blockRefObj As AcadBlockReference
    Dim textString As String
    Dim insertionPoint(0 To 2) As Double
    Dim height As Double

  Form1.lblAblauf.Caption = " Zeichnen Texte / Symbole"
  Form1.lblAblauf.Visible = True
  Form1.ProgBar.Min = 0
  Form1.ProgBar.Value = 0
  Form1.ProgBar.Max = TGesamt
  Form1.ProgBar.Visible = True

For i = 1 To TGesamt  ' i Global als Currency
  Form1.ProgBar.Value = i
    ' Define the text object
    insertionPoint(0) = Texte(i).Tx
    insertionPoint(1) = Texte(i).Ty
    insertionPoint(2) = 0#
    height = 1.8
   
    Select Case Texte(i).KZ
      Case 2450, 3450, 4450, 5450: ' Symbol
          textString = "SYM" + Format(Val(Texte(i).Text), "000")
          Set blockRefObj = ThisDrawing.ModelSpace.InsertBlock(insertionPoint, textString, 1#, 1#, 1#, 0)
          If Texte(i).Ta > 0 Then
'            blockRefObj.Rotation = (500# - Texte(i).Ta) / rho
'            'geändert da die Symbole in der DFK Vorlage schon um 100 gedreht sind !
            blockRefObj.Rotation = (400# - Texte(i).Ta) / rho
          End If
          Call Symbol_Layer(blockRefObj, Texte(i).KZ)
          blockRefObj.Update
      Case Else ' Text
          textString = Texte(i).Text
          Set TextObj = ThisDrawing.ModelSpace.AddText(textString, insertionPoint, height)
          If Texte(i).Ta > 0 Then
            TextObj.Rotation = (500# - Texte(i).Ta) / rho
          End If
          Call Text_Layer(TextObj, Texte(i).KZ)
          TextObj.Update
    End Select
   
    DoEvents
Next i

End Sub

---

Also ganz banal und ohne Attribute. Blöcke in der Vorlage sollten ok sein (nur sehr viele, da die 204 vom Vermessungsamt vorgegeben sind).
Idee mit .Net ist vielleicht gar nicht so schlecht. hat man da Zugriff auf aktive Zeichnung? Habe das Visual Studio 2008 vor kurzem installiert, aber noch keine Zeit gehabt mich damit zu beschäftigen.

Zitat:

---

'ModelSpace.Items.Add' ==> geht so nicht, oder?

---

Eben - dazu hatte ich nichts gefunden. Auch kein Hinweis auf "new item" oder ähnliches.
Die Eigenschaften hätte man ja setzten können ...

In der Anlage mal die Vorlagenzeichnung

Grüße,
Klaus 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi Klaus,

was mir auffällt (aber nichts davon probiert):

a) 'DoEvents' ==> ist zwar nett von Dir anderen (Applikationen) gegenüber, aber damit gibst Du Rechenleistung her

b) probier das mit UNDO ausschalten, wenn ich es richtig verstehe, brauchst Du das für Dich und es wird keine Applikation, die ausser Haus geht, dann kannst Du auch damit umgehen

c) Du greifst mehrfach auf Texte(i) zu, bei jedem Zugriff rast Dein Prozessor das Memory/den Array durch, das geht am Anfang noch schnell, aber bei i=70000 muss er bei jedem Texte(i) 70000 Iterationen durchführen (primitiv ausgedrückt), um auf den Wert des Arrayelements zuzugreifen.

d.h. mach's mal so:

Code:

---

For i = 1 To TGesamt  ' i Global als Currency
  Dim tTextObj as Object  'neu, du musst 'Object' gegen Deinen Typ tauschen
  set tTextObj = Texte(i)  'neu einmal Array durchlesen, dann dieses hier verwenden
  Form1.ProgBar.Value = i
    ' Define the text object
    insertionPoint(0) = tTextObj.Tx  'und so wird's dann verwendet
    insertionPoint(1) = tTextObj.Ty  'und so wird's dann verwendet
    ..... alle anderen 'Texte(i)' tauschen gegen 'tTextObj'

---

f) Deine Progressbar ist ok, verstehe ich auch, aber wenn Du diese nicht aktualisierst, bist Du schneller (oder z.B.

Zitat:

---

if (i mod 100) = 0 then

---

.....dann wird's nur jeweils nach 100 Iterationen nachgestellt

g) hast Du schon bemerkt, xxx.Update kostet Zeit, macht AutoCAD sowieso beim nächsten 'Regen'

Mehr find ich auf die Schnelle nicht, jedenfalls mit dotNET Faktor > 1000 schneller!
Lass mich wissen, wie's geholfen hat.

- alfred -

---

....nochwas:

wäre das nicht eventuell eine Aufgabe für FDO?

Wenn Die Punkte mit XYZ (+ Attribute) vorliegen und man/Frau sich einmal spielt mit Stilisierung je Symbol, dann ist das eine einmalige Einrichtung und dann brauch ich nur mehr Datenbank/-Datei austauschen?

- alfred -

---

Hallo Alfred,

Danke für die Tips.
Zu a) doEvents kann man sicher abschalten, aber ich will ja nicht nur zuschauen
zu b) ja - ist nur für mich 
      DFK Konverter gibt`s ja schon zur Genüge am Markt, aber ich bekomme die Daten nirgends so hin, dass ich gleich - und ohne großen Aufwand Topologien bilden kann (Verbindung zum ALB), deshalb schreib ich mirs selber.
      UNDO ausschalten ist ein guter Tip, den gebe ich meistens auch bei großen Datenmengen. hatte ich schon drin
zu c) Sicher dass er jedesmal die Liste neu durchsucht?    Dann muß ich mir wirklich was anderes einfallen lassen. *Heul* war das schön in C ! verkettete Liste - Pointer auf next - fertig.

d) e) hast Du wieder gelöscht ? *lach*
zu f) Progbar optimieren mach ich meist erst wenn Programm läuft. Falls ichs bei den sonst kleinen makros nicht vergesse, weil schnell genug. Aber - guter Tip.
zu g) siehe 1. Beitrag schon getestet.

Zu dotNET nochmal die Frage:

Zitat:

---

Idee mit .Net ist vielleicht gar nicht so schlecht. Hat man da Zugriff auf aktive Zeichnung?

---

Danke einstweilen,

Grüße,
Klaus 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi Klaus,

Zitat:

---

war das schön in C ! verkettete Liste - Pointer auf next - fertig

---

das geht schon, wenn es sich um eine Collection handelt, aber dann darfst Du nicht mit
For i = 1 To TGesamt 

arbeiten, sondern mit
For Each tTextObj in Texte

dann geht das mit dem Next, das Wichtigste ist einfach, dass Du nicht innerhalb Deiner Schleife mehrmals das Zählen (i) durch die 'Texte'-Liste auslöst.

Zitat:

---

Idee mit .Net ist vielleicht gar nicht so schlecht. Hat man da Zugriff auf aktive Zeichnung?

---

Yes Sir, auf die aktive Zeichnung, auf alle geöffneten Zeichnungen und auf Dwg-Files, die Du nur im Memory öffnest (sprich nicht in den Editor lädst)

- alfred -

---

Hallo Alfred,

nachdem ich vor Weihnachten nicht mehr zu .Net kommen werde, wird das einfachste zum Testen wohl das umstellen auf eine Collection sein. Mal sehn wie lange es dann dauert. 2,5 Stunden für 75000 Datensätze sind auf alle Fälle nicht akzeptabel.

Schönen Tag noch, melde mich wieder wenns läuft.

Klaus

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Klaus,

womit hast du dein Proggi denn gemacht? VB6/A oder AutoCAD VBA ?

Wenn du AutoCAD von "aussen" z.B. aus VB6 über die AktivX Schnittstelle steuerst ist das ca. 100 mal langsamer als aus VBA in AutoCAD.

Wilfried Stelberg

------------------
Warum lisp'eln wenn's auch anders geht.
www.ib-stelberg.de

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi,

wenn Du mir Datenbank schickst (Vorlagenzeichnung habe ich ja schon oben), dann mach ich Dir das als Beispiel in dotNET, mal zum testen der Performance

- alfred -

---

Hallo,

Scheint ja wirklich an der Liste zu liegen, bin aber gerade noch am testen. Werde die Ergebnisse der Messungen später hier offenlegen.

@Stelli: Prog ist momentan in AutoCAD VBA. Danke für den Hinweis, dass es über VB6 von außen soviel langsamer ist, dann brauche ich das ja gar nicht erst probieren.

Hab noch mal nachgedacht und festgestellt, dass ich die Texte / Symbole (=Blöcke)- im gleichem Datensatz - ja gleich beim Einlesen zeichnen kann. Damit geht es schneller. Wie es dann bei ESRI läuft muß man sehen, kommt später.

Die Punkte- / Linienliste brauch ich auf alle Fälle für die Erzeugung der Linien. Mal sehen ob das über Recordset schneller geht. ( Hallo Alfred, Dein Hinweis auf Datenbank brachte mich darauf, hast 'ne PM ).

Eventuell geht es ja über ARX schneller, da muß ich mich aber auch erst einarbeiten.

Grüße an alle,
Klaus

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi,

arx im Vergleich zu managed dotNet ist, wenn Du aus Datenbank Daten lest, nicht schneller, aber deutlich weniger leicht zu debuggen.

- alfred -

---

Hallo Klaus,

ich bin ja auch eher fürs selber machen, aber ...

Wenn du öfters DFK Daten einlesen musst dann mach doch ein Cross Grade von Map auf Autodesk Topobase. Da bekommst du eine DFK Schnittstelle und kannst auch gleich die ALB Daten aus eurem DatRi Grubis Format mit einlesen. Abgesehen davon das die Kartenerzeugung aus der Datenbank recht zügig geht hast du eine zentrale Datenverwaltung in der Datenbank. Daraus kannst du beliebige Reports und auch beliebige Bildauschnitte in verschiedenen Darstellungsvarianten erzeugen. Eine Web Auskunft mit dem gleichen Datenbestand ist auch leicht möglich.

Eine Darstellung von 70000 Punkten, in abhängigkeit von diversen Attributten wird wohl nicht länger als 5 sec brauchen, wenn überhaupt.

Wilfried Stelberg

------------------
Warum lisp'eln wenn's auch anders geht.
www.ib-stelberg.de

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Test_InsertBlock.txt Test_InsertBlock.dvb.txt

Hallo Wilfried,     
  

Zitat:

---

.. dann mach doch ein Cross Grade von Map auf Autodesk Topobase

---

wäre traumhaft, aber da spielt leider der Chef noch nicht mit.      Schlage es ja regelmäßig seit zwei Jahren vor, aber wir Vermesser sind da bei den vielen BauIng leider auf verlorenem Posten. Für "normales" Einlesen haben wir zwei Programme, eines kann auch intern Datenbankverknüpfungen machen und die Gebäude schraffiert ausspielen. Diese dann wieder so exportieren, dass auch ArcView was damit anfangen kann ( Nein, ich ärgere mich heute nicht weiter ..).

Die Darstellung des Gemeindegebietes ist auch nicht das Problem, wenn die dwg mal erstellt ist gehts ja ganz zügig. Nur meine DFK-Einleseroutinen sind zur Zeit noch etwas (sehr) langsam. Scheint aber wirklich an der Feldliste zu liegen.

Morgen mehr dazu wenn die Testroutinen durchgelaufen sind.

Grüße,
Klaus       

Nachtrag:
Habe jetzt neben dem Abendprogramm mal einige Testläufe machen lassen. Mit verblüffendem Ergebnissen, die in der Textdatei nachzulesen sind. DVB hängt ebenfalls an.

Der Unterschied ob die Blockkoordinaten direkt eingegeben werden oder aus einer Liste kommen ist gering (bei 100.000 Blöcken ca. 30 Sekunden), ebenfalls geringen Einfluss hat das Formular (an oder aus)
Großen Einfluß dagegen hat der Zeitpunkt der Ausführung. Nach dem Neustart von AutoCAD ist das Programm sehr schnell, je mehr Änderungen gemacht wurden, umso länger braucht das Programm. Nach Neustart 1 Min., nach sechsmaligem Aufruf 4 Minuten. Alle Blöcke werden immer wieder gelöscht, Zurück an/aus hat geringen Einfluß. Was da wohl alles im Speicher hängen bleibt?
Die lange Ausführungszeit hatte wohl auch damit zu tun dass AutoCAD schon über fünf Stunden mit der gleichen Zeichnung beschäftigt war.
Klaus     

[Diese Nachricht wurde von KlaK am 23. Nov. 2008 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi Klaus,

Zitat:

---

Großen Einfluß dagegen hat der Zeitpunkt der Ausführung. Nach dem Neustart von AutoCAD ist das Programm sehr schnell...

---

ist normal, in Schulungen empfehle ich, AutoCAD (insbesondere wenn es sich um Map3D oder Civil3D handelt) alle 2 Stunden mal zu schliessen, im Taskmanager warten, bis es sich wirklich beendet hat, und dann neu zu starten.

Begründung: Das Betriebssystem kann nicht alle Speicherreservierungen so freigeben, dass diese wieder vollständig genutzt werden können (so wächst der Speicherbedarf kontinuierlich) und zusätzlich entsteht im Speicher eine Fragmentierung, die durchgängiges Lesen eines Blocks immer langsamer werden lässt.

- alfred -

PS: hast neue Version in Mail

---

Hallo,

da sieht man es mal wieder

Zitat:

---

Das Betriebssystem kann nicht alle Speicherreservierungen so freigeben, ..

---

Ob's wirklich das Betriebssystem ist ?? Oder die unsaubere Programmierung bei AutoDesk? (Wie war das mit malloc() / free()? ) Evtl. ist AutoCAD ja auch einfach nur zu überladen mit Objektorientierter Programmierung.
Andere Programme haben damit keine Schwierigkeiten. 50 Mill. Punkte in SMS oder ArcView sind überhaupt kein Thema, in Civil ist ein Programmabsturz gerantiert (mit Land Development Desktop 2004 ging's noch).    Eine Fehlermeldung bezüglich C-Runtime bekomme ich auch nur bei AutoCAD und wenn ich mir die Threats zu AutoCAD 2009 so ansehe ist es nur noch schlimmer geworden. Ist aber ein anderes Thema.

Grüße,
Klaus 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi,

ich stelle mich in der Regel nicht sehr oft vor Autodesk, um sie für Fehler zu verteidigen (liegt schon daran, dass ich wahrscheinlich zu viel udn zu lange damit zu tun hab und daher einiges an Überraschungen erlebt habe ) aber in diesem Fall hinkt Dein Vergleich, da die Ansätze der Produkte unterschiedlich sind.

AutoCAD (und davon abgeleitete vertikale Applikationen) arbeiten auf Basis Einzelelemente hinzuzufügen/zu löschen/zu bearbeiten, d.h. 'malloc', 'calloc', ... geht da immer in kleinen Schritten hinauf, damit entsteht das Problem, dass ein reservierter Speicher irgendwo zwischendrinn kaum so freizugeben ist, dass dieser sofort (und performant) nachfolgenden alloc's zur Verfügung stehen kann (und das ist leider Windows).

Mit Produkten, die 'gewohnt sind' auf große Packages zuzugreifen, steht meist schon vor Speicherbefüllung fest, wie groß diese zu sein hat und kann daher ganz anders alloziiert/initialisiert/befüllt werden. Da gibt's dann kein einzeln dazu und einzel weg als Hauptaufgabe. BTW probier mal im ArcGIS 25mal (ohne ArcGIS zu beenden, im gleichen Projekt) ein Shape zu öffnen/Stilisierung einzustellen und dann wieder zu schliessen. Am Ende schaust Du Dir an, wieviel Speicher von dem da ist, was Du am Anfang noch mit dem leeren Projekt hattest

- alfred -

PS: das mit 2009 geb ich Dir absolut recht