![]() |
AW: Abschlussprojekt FIAE (Optimierung von Algorithmen) -> Vergleich von Polygonen
Zitat:
Also NewCapacity := Round(1.5 * OldList.Count) so als Startwert, man kann sich rantasten. Damit ist der Platz schonmal vor reserviert und es kann ja durchaus vorkommen, dass keine Doppelungen vorkommen. Immer wenn not IsListItemEqual dann wahr wird, kann der aktuelle Eintrag hinzugefügt werden. |
AW: Abschlussprojekt FIAE (Optimierung von Algorithmen) -> Vergleich von Polygonen
Hoi,
gemeint ist ![]() Gemeint ist also das Messen der Zeiten in Deinen alten Code um herauszufinden wo es klemmt. |
AW: Abschlussprojekt FIAE (Optimierung von Algorithmen) -> Vergleich von Polygonen
In manchen Delphi Versionen war eine Lite Version von AQTime dabei, es gibt aber auch andere Profiler.
Hat man ein neu genuges Delphi findet man glaube ich auch einen in GetIt, was ja aber in XE2 noch nicht vorhanden ist, falls das wirklich die von dir genutzte Version ist. Natürlich haben neuere Delphi versionen auch die eine oder andere Performance Verbesserung mit drin... |
AW: Abschlussprojekt FIAE (Optimierung von Algorithmen) -> Vergleich von Polygonen
Zitat:
Zitat:
Wäre den Threading einen Blick wert, z.B. beim Hinzufügen nicht doppelter Elemente zu den temporären Listen, also um das befüllen beider temporärer Listen zu parallelisieren oder macht es bei nur zwei Listen keinen Sinn? |
AW: Abschlussprojekt FIAE (Optimierung von Algorithmen) -> Vergleich von Polygonen
Zitat:
Deshalb zu Beginn mit NewCapacity := OldList.Count allokieren und nach dem Hinzufügen ein TrimExcess? Oder sollte die Allokation besser blockweise (256, 512, 1024) geschehen? |
AW: Abschlussprojekt FIAE (Optimierung von Algorithmen) -> Vergleich von Polygonen
Ein paar Anmerkungen:
Es benötigt ein bisschen mehr als den oben von dir skizzierten Test, denn diese Testdaten verursachen nicht die durchaus teuren Operationen in deinem Code (z.B. Liste rotieren) Generell sei gesagt, dass es nur schneller werden kann, wenn du auf die temporäre Liste verzichtest und sowohl identische Vektoren als auch unterschiedliche Startpositionen direkt abhandelst. Bei Code, der auf jeden Fall garantiert, dass du auf gültige List Indizes zugreifst (durch eine 0 to Count-1 Schleife gegeben), kann es durchaus einen kleinen Schub geben, wenn du AList.List[i] benutzt, dadurch wird der getter übergangen, der noch einen Index in range check durchführt und deshalb obwohl geinlined den Code etwas aufbläht. IsListItemEqual auf jeden Fall als inline markieren (daran denken, diese Funktion vor die anderen zu setzen, da der Compiler nur dann wirklich inlined) Zum Profilen würde ich dir ![]() ![]() Zum Benchmarken möchte ich ![]() |
AW: Abschlussprojekt FIAE (Optimierung von Algorithmen) -> Vergleich von Polygonen
Zitat:
Den Programmen werde ich mich morgen bzw. das Wochenende an meinem privaten Rechner zuhause widmen. Hat denn AQtime auch in der Standard-Version aus dem GetIt-Manager einfache Profiling-Strukturen wie z.B. das Aufzeigen von Speicherressourcen, oder muss ich dafür die PRO-Version erwerben? Oder ist gar der SamplingProfiler kostenlos? Sieht mir etwas altbacken aus, funktioniert der gar mit Delphi 10.4? |
AW: Abschlussprojekt FIAE (Optimierung von Algorithmen) -> Vergleich von Polygonen
Ich würde hier nicht mit Profiling ansetzen, um irgendwo ein paar Takte zu sparen, sondern an dem Algorithmus an sich ...
Wenn ich nicht komplett danebenliege, würde ich an der (ziemlich teuren) RotateList-Funktion ansetzen - die kann doch so ziemlich ersatzlos weg! Diese Rotation um den StartIndex wird doch nur benutzt, damit du in der Schleife ListA[i] mit ListB[i] vergleichen kannst. Warum lässt du das nicht weg, und vergleichst ListA[i] mit ListB[(StartIdx + i) mod ListB.Count]? Dann ersparst du dir sämtliches Umkopieren der Listen (nach dem "Aufräumen"), und dein Algorithmus dürfte um ein Vielfaches schneller werden, da du damit einen Faktor von O(n^2) aus der Laufzeit rausnimmst (solange dauert das Rotate nämlich im Mittel!) Dazu musst du ggf. die beiden Polygondarstellungen auf "offen" normieren (dazu hats du ja die passenden Funktionen), damit Start/Endpunkt auf keinen Fall doppelt vorkommen. Interessant wird da höchstens noch der Fall, wenn du Kantenzüge zulässt, die sich selbst kreuzen, und somit ggf. eine Koordinate mehr als einmal auftauchen darf. Aber dann wird das Problem ohnehin schwieriger, weil du an diesen Kreuzungen ggf. anders "abbiegen" kannst, was letztlich auf Graphisomorphie rausläuft. Und das ist dann so schwierig, dass man nichteinmal weiß, ob es NP-vollständig ist oder nicht. :stupid: (Wobei es für den Spezialfall "Graphen mit Eulerweg" auch eventuell effiziente Tests geben könnte, da bin ich jetzt aber überfragt). |
AW: Abschlussprojekt FIAE (Optimierung von Algorithmen) -> Vergleich von Polygonen
Zitat:
Zitat:
Zitat:
Zitat:
Die Anmerkung zum Profiling war zur Unterstützung und Bestätigung, denn bei entsprechenden Testdaten (die ebend nicht die sind, die weiter oben im Thread gezeigt wurden) dürfte man ziemlich schnell und einfach sehen, dass das befüllen der temp Liste und das rotieren nen dicken Anteil der Laufzeit beansprucht. Nicht jeder sieht seinem Code gleich sein asymptotisches Verhalten an :) |
AW: Abschlussprojekt FIAE (Optimierung von Algorithmen) -> Vergleich von Polygonen
Zitat:
Aber vielleicht als Ergänzung: Das haut natürlich besonders stark in dieser Zeile des Originalcodes rein, wenn AStartIdx = 0 ist.
Delphi-Quellcode:
Dann wird die Liste mit 1000 Einträgen 1000 mal im Speicher hin und her kopiert, bevor mit der Überprüfung auf Gleichheit der beiden Listen begonnen wird.
RotateList(LTmpList, (LTmpList.Count - 1) - AStartIdx);
Das mit der Index-Rechnerei mag zwar aufwändiger erscheinen, ist es aber nicht. Schon alleine deswegen, weil bei ungleichen Polygonen es sehr schnell zu einem Abbruch kommen wird, während sich die Rotation grade erst warmgelaufen hat. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:27 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz