AMD Codeanalyst + Optimierung



  • Ich habe einen Funktionsplotter (GFPlot) erstellt und bin jetzt an das Optimieren gegangen. Zu diesem Zweck hab ich mir den AMD Codeanalyst runtergeladen (ich hab zwar eine Intel-CPU, aber TimeSampling geht trotzdem).

    Wenn ich z.B. eine Spirale (in Polarkoordinaten) mit der Liniendicke 2, dann ist die Performance nur mäßig.

    Codeanalyst zeigt mir folgende Verteilung der TimerSamples in meinem Prozess an:
    - Unknown Kernel Samples: 81,28
    - ntdll.dll: 5,73
    - MSVCR90.dll: 4,51
    - GFPlot.exe: 3,69
    - mfc90u.dll: 3,47
    (und noch ein paar andere <0.34)

    Weis einer, was diese "Unknown Kernel Samples" sind? Google lieferte mir nur 1 (unbrauchbares) Ergebnis und wenn ich doppelt drauf klicke, crashed Codeanalyst (und damit das komplette VS2008).

    In der GFPlot.exe selber benötigt die Draw-Funktion am meisten Performance: 22,98, wobei der folgende Code alleine 42,48% benötigt:

    if (CurrentLPPoint->ExtraInfo == DH_NONE && CPoint(CurrentDPPoint) == OldDPPoint)
          {
            ++CurrentIndex;
            continue;
          }
    

    Dieser Code wird für jeden berechneten Punkt aufgerufen und filtert Punkte aus, die den selben Pixel ergeben würden.
    Ich nehme an, dass die hohe Prozentzahl einfach daran liegt, dass ich Massen an Punkten habe (kann ich bei polaren Funktionen nicht wirklich ändern).

    Wie geht man an die Optimierung von Funktionen heran? Ich sehe da eben keine Möglichkeit, irgendetwas zu optimieren...

    Kann man irgendwie die GDI-Aufrufe optimieren?

    Also, 3 Fragen: Was sind diese "Unknown Kernel Samples" oder wie kann ich sie "bekannt machen", wie geht man an die Optimierung von Programmen ran und kann man die GDI-Aufrufe optimieren?

    Danke,
    Gugi



  • ist dieser Construtoraufruf in der IfAbfrage notwendig?

    Edit:
    wenn die punkte unterschieldiche Typen haben, sollte es performatnter sein, die komponenten der punkte einzeln zu vergleichen, anstatt extra ein neues Objekt anzulegen, was sofort wieder verworfen wird, nur um einen überladenen == operator aufzurufen



  • Ja, das habe ich auch schon probiert:

    if (CurrentLPPoint->ExtraInfo == DH_NONE && rounded_cast<int>(CurrentDPPoint.x) == OldDPPoint.x && rounded_cast<int>(CurrentDPPoint.y) == OldDPPoint.y)
    

    Hat allerdings nichts gebracht, egal in welcher Reihenfolge die 3 Tests angeordnet waren.



  • Weiß jemand, ob man folgende Funktion in irgendeiner Weise optimieren kann? Sie überprüft, ob sich die Zahl ToCheck zwischen (MidNum-Tolerance) und (MidNum+Tolerance) befindet.

    bool
    GCalc::HelperFunctions::IsInRange(const double& ToCheck, const double& MidNum, const double& Tolerance)
    {
      return (ToCheck > (MidNum-Tolerance) && ToCheck < (MidNum+Tolerance));
    }
    

Log in to reply