powered by CADENAS

Manual

Manual

1.1.6.7.10.3. Suchergebnisse im Arbeitsspeicher cachen

Die meiste Zeit bei der Suche wird für das Lesen der Daten von der Festplatte benötigt. Deswegen ist die Suche schneller, wenn Ergebnisse im Arbeitsspeicher gecached werden.

Das Cachen ist insbesondere bei Nutzung eines Such-Servers empfohlen.

[Hinweis] Hinweis

Bei Neustart vom PARTdataManager oder Such-Server geht der Cache verloren. Somit ist effektives Cachen nur bei der Nutzung eins Such-Servers möglich, da dieser in der Regel nur in besonderen Fällen neu gestartet wird.

[Hinweis] Hinweis

Neben dem hier beschriebenen Caching gibt es noch ein Caching zwischen den Indexdateien unter $CADENAS_DATA\index und dem Such-Server.

Wichtige Informationen hierzu finden Sie unter Abschnitt 1.1.6.7.9.2, „Indexdateien von $CADENAS_DATA auf Such-Server cachen“.

In der Konfigurationsdatei geomsearch.cfg gibt es unterschiedliche Blöcke für das Caching:

  • Caching für die Versionen bis 9.07

    [Cache_Local_Search]
    [Cache_Server_Search]

    [Hinweis] Hinweis

    Die Einstellungen bleiben insofern auch für Versionen ab 9.08 relevant, weil diese optional auch den "alten" Suchindex nutzen können.

  • Caching für die Versionen ab 9.08

    [CACHEV2_GEO_SEARCH_32]
    [CACHEV2_GEO_SEARCH_64]

In den beiden folgenden Abschnitten werden die Blöcke getrennt behandelt:

1.1.6.7.10.3.1. Caching für die Versionen bis 9.07

1.1.6.7.10.3.1.1. Beschreibung der unterschiedlichen Caches

Ausschnitt aus $CADENAS_SETUP -> geomsearch.cfg

[Cache_Local_Search]
maxOpenIndexCount=100
linIndexCacheSize=0
sampleLineListCacheSize=0
pivotDistListCacheSize=0
logFileName=

[Cache_Server_Search]
maxOpenIndexCount=100
linIndexCacheSize=150000
sampleLineListCacheSize=800000
pivotDistListCacheSize=50000
logFileName=

[Hinweis] Hinweis

Der Cache kann für die lokale Suche und für die Suche per Such-Server getrennt eingestellt werden.

Das Cachen funktioniert auch mit PARTdataManager, kann hier allerdings nicht effektiv betrieben werden, da der Cache jedesmal bei Neustart verloren geht. Daher sind die Werte linIndexCacheSize, sampleLineListCacheSize und pivotDistListCacheSize für die lokale Suche auf '0' gesetzt.

Im Folgenden finden Sie eine Beschreibung zu den einzelnen Caches:

  1. maxOpenIndexCount: Verhindert, dass der Index für jede Suche neu geöffnet werden muss.[13]Der eingestellte Wert entspricht der max. Anzahl von offenen Indices.

    Stellen Sie den Wert auf die Anzahl der zu durchsuchenden Kataloge ein (hier im Beispiel '100').

    maxOpenIndexCount=100
  2. sampleLineListCache:

    Cache für Fingerprints

    (Cache ist für alle Threads [entspricht in der Regel der Anzahl der Prozessorkerne] zusammen (vgl. $CADENAS_SETUP/partsol.cfg -> Block "SEARCHSERVER" -> Schlüssel "THREADS")

    Beispiel: 80% von 1GB zur Verfügung stehendem RAM (Angabe in KB)

    sampleLineListCacheSize=800000

    [Empfehlung: Für die Ersteinstellung 80%]

  3. linIndexCache: (nicht verwendet bei der Suche über Sketche)

    Cache für linearen Index

    Beispiel: 15% von 1GB zur Verfügung stehendem RAM (Angabe in KB)

    linIndexCacheSize=150000

    [Empfehlung: Für die Ersteinstellung 15%]

  4. pivotDistListCache: (nicht verwendet bei der Suche über Sketche)

    Cache für linearen Index:[14]

    (Cache ist für alle Threads [entspricht in der Regel der Anzahl der Prozessorkerne] zusammen (vgl. $CADENAS_SETUP/partsol.cfg -> Block "SEARCHSERVER" -> Schlüssel "THREADS")

    Beispiel: 5% von 1GB zur Verfügung stehendem RAM (Angabe in KB)

    pivotDistListCacheSize=50000

    [Empfehlung: Für die Ersteinstellung 5%]

1.1.6.7.10.3.1.2. Log-Datei auswerten - Beste Einstellungen finden

Die Einstellungen optimieren Sie am besten in 2 Schritten:

  1. Setzen Sie die Einstellungen im ersten Schritt nach einem allgemeinen Erfahrungswert:

    1. Bestimmen Sie, wieviel Prozent des Arbeitsspeichers Sie dem Cache zuweisen können, ohne andere Prozesse einzuschränken.

    2. Teilen Sie diesen Arbeitsspeicher in folgendem Verhältnis auf:

      • sampleLineListCacheSize: 80%

      • linIndexCacheSize: 15%

      • pivotDistListCacheSize: 5%

    3. Tragen Sie die Ergebniswerte in KB in die oben genannten Schlüssel ein.

    4. Setzen Sie den Schlüsselwert von maxOpenIndexCount auf die Anzahl der zu durchsuchenden Kataloge.

    [Hinweis] Hinweis

    Wenn Sie alle Werte auf '0' setzen, ist das Caching deaktiviert.

  2. Optimierung der Werte nach Auswertung der Log-Datei

    In der Konfigurationsdatei geomseach.cfg geben Sie an, wohin die Log-Datei gespeichert werden soll.

    [Hinweis] Hinweis

    Bei jeder Suche wird ein Bericht ausgegeben, wieviele Cache-Treffer es gab und wieviel Speicherplatz benötigt wurde. Die Werte werden nach der Suche nicht zurückgesetzt. Die Statistik läuft über alle Suchen!

    Bei Neustart des PARTdataManager, bzw. des Such-Servers wird die Log-Datei gelöscht.

    Um zu optimalen Einstellungen für die Geometrische Suche zu gelangen, beachten Sie bitte folgendes, bevor Sie die Log-Datei auswerten:

    • Führen Sie Suchen aus, die in etwa dem normalen Benutzerverhalten entsprechen, zum Beispiel bei der Auswahl der Suchvorlagen, Skizzensuche oder 3D-Suche, aber auch bei der Auswahl der Suchteile.

    • Lassen Sie die Suche im Idealfall mehrere Tage (Search-Server), bzw. über eine längere Benutzungsphase des PARTdataManagers laufen, bevor Sie die Log-Datei auswerten.

Beispiel zur Auswertung der Log-Datei

GeoIndexCache CacheHits 999 of 1000, 99%
GeoIndexCache Files 99 of 100, 99%

SampleLineListCache CacheHits 999 of 1000, 99%
SampleLineListCache Memory 400000 of 800000, 50%

LinIndexCache CacheHits 10617 of 10776, 98%
LinIndexCache Memory 90000 of 100000, 90%

PivotDistCache CacheHits 100 of 10000, 1%
PivotDistCache Memory 9999 of 10000, 99%

Beim GeoIndexCache müssen Sie nichts verändern. Dieser ist eingestellt auf die Anzahl der zu durchsuchenden Kataloge.

Bei den übrigen drei Caches gelten folgende Regeln: (Hier beispielhaft für SampleLineListCache erläutert. Die Aussagen sind auf LinIndexCache und PivotDistCache übertragbar.)

CacheHits

Die erste Zeile zeigt die Anzahl der Treffer = Maß für die Qualität

SampleLineListCache CacheHits 900 of 1000, 90%
  1. Der erste Wert (hier 900) zeigt die Anzahl der Zugriffe auf Elemente, die bereits im Cache vorhanden sind.

    Der zweite Wert (hier 1000) zeigt die Gesamtanzahl der Zugriffe.

  2. Der zweite Wert gibt das Verhältnis der beiden Werte in Prozent an. Hier 90%.

Memory

Die zweite Zeile zeigt die Nutzung des Arbeitsspeichers:

SampleLineListCache Memory 600000 of 800000, 75%
  1. Die ersten beiden Werte geben an, wieviel KB vom in der Konfigurationsdatei eingestellten KB-Wert benutzt wurden.

    Im Beispiel wurden 600000 KB von 800000 KB benutzt.

  2. Der zweite Wert gibt das Verhältnis der beiden Werte in Prozent an. Hier 75%.

CacheHits ist das Maß für die Qualität der Cache-Nutzung. Ist dieser Wert hoch, sind die Einstellungen Ok.

Memory gibt Auskunft, ob der in der Konfigurationsdatei eingestellte Wert richtig dimensioniert ist. Wenn man bei CacheHits 100% hat und bei Memory 10%, so wird man mit deutlich weniger Zuweisung ebenso gute CacheHits bekommen.

Sind die CacheHits niedrig (z.B. 10%) und der eingestellte Cache wird voll genutzt (z.B. 100%), so sollte versucht werden, durch ein Hochsetzten des Cache-Wertes die Trefferquote zu erhöhen.

1.1.6.7.10.3.2. Caching für die Versionen ab 9.08 / Neuer Geometrischer Suchindex

Um die Performanz bei der Geo-Suche und der Topologie-Suche zu verbessern, wurde der Aufbau des Geo-Index mit Version 9.08 komplett überarbeitet. Im Folgenden finden Sie die wichtigsten Informationen hierzu.

1.1.6.7.10.3.2.1. Neue Struktur der Indizes

Mit V9.08 ergeben sich einige Änderungen bezüglich Speicherort und Dateien:

Speicherort

$CADENAS_DATA\index\cat\...\

Der Geo-Index und der Topo-Index werden nun getrennt gespeichert.

Der neue Geo-Index liegt im Unterordner geoindexv2 (neben dem "alten" geoindex), der Topo-Index im Ordner topoindex.

Folgende Dateien liegen im Verzeichnis geoindexv2:

  1. geomsearch.fdb:

    Diese Datei enthält die Fingerprints für die einzelnen Algorithmen.

  2. geomsearch.cidb:

    Diese Datei enthält Informationen über das Teil, die nur bei der Erzeugung der Fingerprints relevant sind, d.h. diese Informationen müssen für die Suche nicht gelesen werden.

  3. geomsearch.ldx:

    Diese Datei enthält den Linearen Index für die einzelnen Suchvorlagen.

  4. geomsearch.ofm: Diese Datei enthält ein Mapping von Projektpfaden auf die internen IDs des Geo-Index.

    In einem bestimmten Modus werden die Updates des Geo-Index nicht direkt in den Geo-Index integriert, sondern in spezielle Dateien gespeichert, um den Vorgang zu beschleunigen. Weitere Informationen hierzu finden Sie unter Abschnitt 1.1.6.7.10.3.2.4, „Erzeugung von Geo- und Topo-Indizes“. Die folgenden Dateien werden dafür verwendet:

    • geomsearch.ufdb: Enthält die Fingerprints der Änderungen.

    • geomsearch.ucidb: Enthält Informationen der Änderungen, die bei Suche nicht relevant.

    • geomsearch.uop: Enthält alle nötigen Informationen um die Fingerprints der Änderungen in den Geo-Index integrieren zu können. Unter Umständen wird der Geo-Index gerade bearbeitet.

      In diesem Fall befindet sich eine weitere Datei in diesem Verzeichnis:

      geomsearch.lock: Verhindert, dass während des Schreibens auf den Geo-Index zugegriffen wird.

Folgende Dateien liegen im Verzeichnis topoindex:

  1. topoindex.bin: Diese Datei enthält die strukturierten Topo-Daten.

  2. topoindex.idx: Diese Datei enthält Indizes für die Suche auf den Daten.

    Auch beim Topo-Index gibt es die Möglichkeit der schnellen Updates. Dann liegen noch folgende Dateien in dem Verzeichnis:

    • topoindex.dupd: Die Struktur-Daten der Änderungen

    • topoindex.upd: Informationen, um die Änderungen in den Index integrieren zu können. Eventuell ist auch dieses Verzeichnis gelockt:

    • topoindex.lock: Verhindert, dass während des Schreibens auf den Topo-Index zugegriffen wird.

1.1.6.7.10.3.2.2. Allgemeine Einstellungen

Unter $CADENAS_SETUP/geomsearch.cfg können einige Einstellungen gemacht werden. Diese sind im Block [settings] zusammengefasst.

  1. Schlüssel: searchindex

    Bestimmen Sie, welcher Geo-Index für die Suche verwendet werden soll. Mögliche Werte:

    • old: Verwende alten Index

    • new: Verwende neuen Index

    • both: Verwende neuen Index, falls nicht vorhanden, alten Index

  2. Schlüssel: toposearchindex

    Bestimmen Sie, welcher Topo-Index für die Suche verwendet werden soll. Mögliche Werte:

    • old: Verwende alten Geo-Index

    • new: Verwende neuen Index

    • both: Verwende neuen Index, falls nicht vorhanden, alten Geo-Index

  3. Schlüssel: convertindex und converttopoindex

    Konvertierung alter Indizes in neue Indizes. Mögliche Werte:

    • 0: Konvertierung deaktiviert

    • 1: Konvertierung aktiv. Die Konvertierung erfolgt dann automatisch, wenn ein alter Index erzeugt wird.

  4. Schlüssel: createNewDirectly

    Steuerung, ob alter oder neuer Index erzeugt werden soll. Mögliche Werte:

    • 0: Alten Index erzeugen

    • 1: Neuen Index erzeugen

  5. Schlüssel: createNewLinIndex

    Soll der lineare Index bei der Konvertierung neu erzeugt werden? Mögliche Werte:

    • 0: Alten linearen Index konvertieren. Da dieser Index weniger Pivot-Elemente verwendet, ist die Suche dann etwas langsamer. Dafür geht die Konvertierung sehr schnell.

    • 1: Linearen Index neu erzeugen

1.1.6.7.10.3.2.3. Migration der Indizes

Über das Migrations-Tool unter PARTadmin -> Kategorie -> Katalogaktualisierung -> Migration (siehe Abschnitt 1.1.3.3.4, „Migration“) können beliebig viele Kataloge auf einmal migriert werden. Es wird empfohlen hierfür die 64-Bit-Variante von PARTadmin zu verwenden, da die Konvertierung dann wesentlich schneller geht, da mehr Speicher zur Verfügung steht. Der Norm-Katalog kann nur als Ganzes migriert werden. Es ist nicht möglich z.B. nur norm/din zu migrieren.

1.1.6.7.10.3.2.4. Erzeugung von Geo- und Topo-Indizes

Für die Erzeugung der Indizes gibt es grundsätzlich 3 Möglichkeiten:

  1. Neu-Erzeugung des Geo-Index

  2. Update des vorhandenen Index (Arbeiten auf Kopie). Hier kann der vorhandene Index auch ein alter Geo-Index sein. Dieser wird dann automatisch konvertiert.

  3. Update des vorhandenen Index (Arbeiten mit speziellen Update-Dateien). Sinnvoll, wenn man auf großen Katalogen kleine Änderungen macht.

    • Variante 3 ist wesentlich schneller als Variante 2, besonders auf großen Katalogen.

    • Variante 3 hat den Nachteil, dass die Suche langsamer wird, je mehr dieser Updates hinzugefügt werden. Deshalb ist es sinnvoll, hin und wieder den Index im Modus 2 zu aktualisieren, da die Updates dann komplett in den Index integriert werden.

    • Die Pivot-Elemente des Linearen Index werden in Variante 3 nicht neu bestimmt. Auch das kann sich negativ auf die Suchzeiten auswirken.

Weitere Hinweise

  • Die Erzeugung von Geo- und Topo-Index geschieht immer gemeinsam.

  • Grundsätzlich gilt auch hier wie bei der Migration, dass mit 64 Bit eine bessere Performanz erzielt werden kann.

  • Während der Generierung der Indizes sind die Verzeichnisse vom Geo- und Topo-Index gelockt. Die Varianten 1 und 2 arbeiten auf einer temporären Kopie. Hier wird das Verzeichnis am Anfang nur für Schreibzugriffe gesperrt, d.h. der Index kann noch gelesen werden. Der Index muss nur kurz für das Lesen gesperrt werden, wenn die alten Dateien gelöscht und die temporären umbenannt werden. Die 3. Variante arbeitet nicht auf einer Kopie. Deshalb muss während des gesamten Updates gelockt werden.

  • Über den Schlüssel ThreadCountForLinearIndexCreator im Block settings_32 bzw. settings_64 kann festgelegt werden, wie viele Threads verwendet werden sollen, um den linearen Index zu erzeugen. Setzt man den Wert auf -1, dann wird die Anzahl der Kerne herangezogen. Jeder Thread benötigt unter Umständen einige hundert MB Arbeitsspeicher, deshalb machen zu hohe Werte für 32 Bit keinen Sinn.

    Beispiel:

    [settings_32]
    ThreadCountForLinearIndexCreator=2
    
    [settings_64]
    ThreadCountForLinearIndexCreator=-1
1.1.6.7.10.3.2.5. Änderungen bei der eigentlichen Suche

Für Geo- und Topo-Index gibt es jeweils 3 verschiedene Modi für die Ausführung der Suche, je nachdem, was in der geomsearch.cfg im Block settings festgelegt wurde (siehe oben).

  • new: Nur der neue Index wird verwendet, wenn nicht verfügbar, gibt es für diesen Katalog keine Ergebnisse.

  • both: Falls möglich, wird der neue Index verwendet. Nicht verfügbare Indizes werden gegebenfalls im Speicher konvertiert.

  • old: Suche mit alten Indizes

Außerdem wird ab V9.08 für die Skizzensuche auch der Lineare Index verwendet, um die Suchzeit zu reduzieren.

1.1.6.7.10.3.2.6. Caching-Einstellungen

Alle Caching-Einstellungen können für PARTdataManager 32 Bit und 64 Bit unterschiedlich gesetzt werden.

Geo-Suche
  • LinIndexCacheSize: Größe des Caches für den linearen Index in KB

    Wählen Sie den Wert so, dass er nicht ganz ausgeschöpft wird.

    Wenn dies nicht möglich ist, den hierfür primären Speicher (SampleLineCacheSize) klein wählen.

    [CACHEV2_GEO_SEARCH_32]
    LinIndexCacheSize=100000

    [CACHEV2_GEO_SEARCH_64]
    LinIndexCacheSize=300000
  • OffsetCacheSize: Größe des Caches für den Offset-Index in KB

    Wählen Sie den Werte so, dass er nicht ganz ausgeschöpft wird.

    Wenn dies nicht möglich ist, den hierfür primären Speicher (SampleLineCacheSize) klein wählen.

    [CACHEV2_GEO_SEARCH_32]
    OffsetCacheSize=50000

    [CACHEV2_GEO_SEARCH_64]
    OffsetCacheSize=150000
  • GeoIndexV2CacheSize: Anzahl von Geo-Indizes, die gleichzeitig geöffnet sein können.

    Setzen Sie den Wert so, dass er der maximale Anzahl an Katalogen entspricht.

    [CACHEV2_GEO_SEARCH_32]
    GeoIndexV2CacheSize=1000

    [CACHEV2_GEO_SEARCH_64]
    GeoIndexV2CacheSize=1000
  • SampleLineCacheSize: Cache für Fingerprints in KB

    Cache ist für alle Threads (entspricht in der Regel der Anzahl der Prozessorkerne zusammen)

    [CACHEV2_GEO_SEARCH_32]
    SampleLineCacheSize=100000

    [CACHEV2_GEO_SEARCH_64]
    SampleLineCacheSize=500000
  • LogFileName: Hier werden Log-Informationen gespeichert falls nicht leer. Siehe unten.

    Setzen Sie den Schlüssel selbst, sofern er nicht vorhanden ist.

    [CACHEV2_GEO_SEARCH_32]
    LogFileName=c:\log\cachev2_geo_search_32.log

    [CACHEV2_GEO_SEARCH_64]
    LogFileName=c:\log\cachev2_geo_search_64.log

[Wichtig] Wichtig

Bei der Geo-Suche sollte man nach folgenden Regeln die Werte setzen:

  1. LinIndexCacheSize und OffsetCacheSize so groß wählen, dass sie nicht ganz voll werden. Wenn dies nicht möglich ist, Speicher primär hierfür, SampleLineCacheSize klein wählen.

  2. Falls noch Speicher übrig, setzen Sie SampleLineCacheSize so groß wie möglich.

Topo-Suche
  • ObjectDataCacheSize: Cache für Topo-Daten-Knoten

    Insbesondere wichtig für die Migration.

    [CACHE_TOPO_SEARCH_32]
    ObjectDataCacheSize=200000

    [CACHE_TOPO_SEARCH_64]
    ObjectDataCacheSize=1000000
  • IndexCacheSize: Cache für Indizes auf den Topo-Daten

    Insbesondere wichtig für die Topo-Suche.

    [CACHE_TOPO_SEARCH_32]
    IndexCacheSize=200000

    [CACHE_TOPO_SEARCH_64]
    IndexCacheSize=500000
  • LogFileName: Hier werden Log-Informationen gespeichert, falls nicht leer. Siehe auch Abschnitt 1.1.6.7.10.3.2.7, „Log-Datei auswerten - Beste Einstellungen finden“.

    Setzen Sie den Schlüssel selbst, sofern er nicht vorhanden ist.

    [CACHE_TOPO_SEARCH_32]
    LogFileName=c:\log\cachev2_topo_search_32.log

    [CACHE_TOPO_SEARCH_64]
    LogFileName=c:\log\cachev2_topo_search_64.log
1.1.6.7.10.3.2.7. Log-Datei auswerten - Beste Einstellungen finden

Mittels der oben erwähnten Log-Dateien (Schlüssel LogFileName) können die Sucheinstellungen für die vorhandenen Daten und das Suchverhalten optimiert werden. Aus der Log-Datei kann entnommen werden, wie voll die jeweiligen Caches sind und wie oft bei einem Zugriff das Element tatsächlich im Cache war (Cache-Hit).

Beispiel:

Search from Do 12. Dez 22:41:09 2013
Thread: 0xce8

Geometrical index cache: 
Capacity of the cache: 1000
In use: 18 (1.80%)
Free: 982 (98.20%)
Accesses to the cache: 6489
Cache hits: 6471 (99.72%)
Cache misses: 18 (0.28%)

Linear index cache: 
Capacity of the cache: 100000
In use: 4962 (4.96%)
Free: 95038 (95.04%)
Accesses to the cache: 1932
Cache hits: 1615 (83.59%)
Cache misses: 317 (16.41%)

Offset index cache: 
Capacity of the cache: 50000
In use: 1617 (3.23%)
Free: 48383 (96.77%)
Accesses to the cache: 7033
Cache hits: 6716 (95.49%)
Cache misses: 317 (4.51%)

Sample lines cache: 
Capacity of the cache: 100000
In use: 82785 (82.78%)
Free: 17215 (17.22%)
Accesses to the cache: 16840
Cache hits: 10985 (65.23%)
Cache misses: 5855 (34.77%)

Einige Hinweise für die Interpretation der Daten:

  1. Die Log-Datei wird unter Umständen erst vor der nächsten Suche aktualisiert.

  2. Um mithilfe der Log-Datei sinnvolle Einstellungen zu machen, ist es wichtig, mehrere Suchen ausführen, die in etwa dem normalen Benutzerverhalten entspricht, zum Beispiel bei der Auswahl der Suchvorlagen, Skizzensuche oder 3D-Suche, aber auch bei der Auswahl der Suchteile.

  3. Die Informationen über Cache-Hits und Cache-Misses, die nach jeder Suche ausgegeben werden, sind kumulativ.

  4. Die Daten werden immer erst beim ersten Zugriff in den Cache geladen. Also ist der erste Zugriff auf Daten immer ein Cache-Miss. Je mehr Suchen ausgeführt, desto weniger Cache-Misses sollten hinzukommen.

1.1.6.7.10.3.2.8. Zugriff auf Topo-Werte über VBS

Auf die Topo-Werte kann folgendermaßen zugegriffen werden:

' main class to manage topology
set topoManager = CreateObject("cnstools.topomanager")

' fetch root node of topology tree
set catalogRoot = topoManager.findCatalogRoot("cat/norm/din")
stdprint("Number of project in din: " & catalogRoot.childCount)

' fetch project node
set prjNode = topoManager.findProjectNode("cat/norm/din", "anlagenbau/armaturen/
 din_11864_1_a_asmtab.prj")
stdprint("Number of lines in anlagenbau/armaturen/din_11864_1_a_asmtab.prj: " 
 & prjNode.childCount)

' fetch line node
set lineNode = topoManager.findLineNode("cat/norm/din", "anlagenbau/armaturen/
 din_11864_1_a_asmtab.prj", 20)

' helper to recursively print all the attributes of a node
sub printAttributes(node, indent)
	stdprint(indent & node.name)
	c = node.childCount
	for j = 0 to c - 1
		printAttributes(node.child(j), indent & "  ")
	next
	a = node.attributeCount
	for j = 0 to a - 1
		set attr = node.attribute(j)
		value = attr.value
		valueAsString = ""
		set attrType = attr.type
		if attrType = "doubleVec" then
			n = value.count
			for k = 0 to n - 1
				if k > 0 then
					valueAsString = valueAsString & ", "
				end if
				valueAsString = valueAsString & value.item(k)
			next
		else
			valueAsString = value
		end if
		stdprint(indent & "  " & attr.name & ": " & valueAsString)
	next
end sub

' print all attributes for a line
stdprint("Recursive list of all attributes in line 20:")
stdprint()
printAttributes(lineNode, "")
stdprint()

' print all attributes for a stl file
stdprint("Recursive list of all attributes in stl:")
stdprint()
set stlNode = topoManager.createNodeFrom3DFile("D:/stl/1 stl/001952002.stl", "STLFILE")
printAttributes(stlNode, "")

' print all attributes for a prt file
stdprint()
stdprint("Recursive list of all attributes in prt file:")
stdprint()
set prtNode = topoManager.createNodeFrom3DFile("D:/stl/ein paar proe-Dateien/
 1202t4100_gen.prt.1", "NATWILDFIREPART 5 32 BIT")
printAttributes(prtNode, "")

' print all attributes for a line (create fingerprints on the fly)
stdprint()
stdprint("Recursive list of all attributes in line 420:")
stdprint()
set lineNode2 = topoManager.createNodeFromProject("cat/norm/din", "anlagenbau/armaturen/
 din_11864_1_a_asmtab.prj", 420)
printAttributes(lineNode2, "")

' print all attributes for a project (create fingerprints on the fly)
stdprint()
stdprint("Recursive list of all attributes in project anlagenbau/armaturen/
 din_11864_1_a_asmtab.prj:")
stdprint()
set prjNode2 = topoManager.createNodeFromProject("cat/norm/din", "anlagenbau/armaturen/
 din_11864_1_a_asmtab.prj", -1)
printAttributes(prjNode2, "")


[13] Er muss nur 1 Mal für jeden "Thread" [entspricht in der Regel der Anzahl der Prozessorkerne] geöffnet werden. Jeder THREAD hat seinen eigene Cache.

[14] Der lineare Index sortiert Teile nach Abständen zu bestimmten Referenzteilen. Diese heißen Pivots.