Hallo Andreas,
Performance in SolidWorks ... eines meiner Steckenpferde
Was schon mal sehr gut ist ist der Ansatz, erst mal herauszufinden, wie man die Performance testen kann, bevor man sie verbessern will. Es gibt nichts schlimmeres als den Ausspruch Ich hab das Gefühl mit der 2007 ist alles langsamer/schneller geworden.
Zahlen sollten für einen Performancevergleich her, möglichst neutral und "ehrlich" aufbereitet; ich weiß selbst sehr gut (eben weil ich das gerne mache ), dass ich jedes Ergebnis, selbst mit Zahlen hinterlegte Meßreihen, statitisch so drehen und verbiegen kann, dass das rauskommt, was ich möchte und schon vorher festgelegt habe.
Dazu gehört als erstes und wichtigstes mal die Frage: Was bedeutet für euch Performance?? Allein schon bei dieser Antwort scheiden sich die Geister, am schlimmsten ist es, wenn man nicht mal eine Idee hat, was wohl mit dieser Performance gemeint ist.
Ist es eine Bestimmte Berechnung eines bestimmten Features?
Die durchschnittliche Rebuildzeit bei einem ForcedRebuild? Für welche Dokumente?
Der Grafikaufbau?
Die Ladezeit?
Die Ausführungszeit eines Makros?
Mit und ohne laufende Addons?
Mit und ohne laufende Hintergrundprozesse wie Virenscanner?
In Labor- oder produktiver Umgebung?
Ein Mischmasch aus allem? Wenn ja, wie gewichtet?
Soll Hardware in die Aussage mit einbezogen werden?
Wird ein Benutzer bei der Performance mit berücksichtigt?
Werden die Prozesse mit berücksichtigt?
Spielen externe/nach- oder vorgelagerte Prozesse eine Rolle?
usw. usw.
Ich hoffe, du verstehst, worauf ich hinaus will. Als erstes ist mal wichtig festzulegen, welche Performance ihr denn meint und auch, was ihr euch davon versprecht. Ich erlebe immer wieder, dass nach schnellerer, stärkerer Hardware mit dem Topprozessor geschrieen wird, die User aber nicht bereit sind andere Arbeitstechniken anzuwenden, die das vielfache der "Gesamtperformance" bringen würden. Oder dass es auch andersherum nicht möglich ist mal 500 EUR für ein Upgrade des Arbeitsspeichers dem Kostenstellenverantwortlichen aus dem Kreuz zu leiern, weil der Konstrukteur ja "auch was anderes in der Zeit machen kann".
Es kommt eben sehr darauf an.
Wenn man dann im Speziellen bei SolidWorks irgendwas wirklich messen will kommt man um Benchmarks (von denen es keine aktuellen frei verfügbar gibt) bzw. eigene Automation nicht drumherum; Performancemessungen unterliegen selbst unter Laborbedingungen den statistischen Randbedingungen und Messsungen sollten immer an möglichst breiter Datenbasis mehrfach durchgeführt und gemittelt werden. Dabei muss natürlich wie oben beschrieben darauf geachtet werden, dass die Tests "fair" sind und nicht schon so ausgelegt werden, dass nichts anderes als das Ergebniss rauskommt, was ich haben will
Wenn man das dann hat (was eben die meisten Leute lieber nicht machen, weil es aufwendig und "gefährlich", weil auslegungsfähig, ist ) geht es meist darum etwas zu finden, wie man das verbessert; ein paar Ansätze hab ich auch meiner Seite geschrieben, wie Kranbauer oben geschrieben hat. Das sind die Powerpointfolien von einem Vortrag, den ich bei CAD.de Anwendertreffen 2005 gemacht hab, aber die Sachen sind alle heute noch gültig. Du findest das und noch eine Menge mehr auf http://solidworks.cad.de/knowhow.htm
Logischweise gibt es noch viel mehr, vor allem jenseits von SolidWorks und direkt beim User und den Prozessen; meist steckt da viel mehr Potential drin, aber oft traut sich da niemand dran, da es viel leichter ist die IT und die Werkzeuge verantwortlich zu machen als seinen Arbeitsstil zu ändern
Aber das ist schwierig in einem Forum zu beschreiben, dafür werden ganze Beraterstäbe bezahlt und auch Admins wie ich haben wegen der entsprechenden Ausbildung und Erfahrung überhaupt einen Brötchengeber
Ciao,
Stefan
------------------
Inoffizielle deutsche SolidWorks Hilfeseite http://solidworks.cad.de
Member of CAD.de BOINC Team - | Seti@Home | CPDN | Einstein@Home
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP