Ich habe mir eine Bibliothek zusammen gebastelt, welche mir aber nach der Fertigstellung ein wenig langsam vorkam. Ich wollte rausfinden woran dies liegt, da ich mir aber keinen Profiler leisten kann oder will und ich mit CodeAnalyst von AMD einfach nicht klar komme, habe ich selber ein paar Messungen durchgeführt. Diese zeigen mir Stellen an, wo das Programm Engpässe hat, wenn ich von ausserhalb messe, ist dies ganz klar, wenn ich es in der Methode messe, stimmt es überhaupt nicht mehr. Es ist für mich ein Rätsel.

Mal ein kurzes Beispiel:
Document.hpp

namespace dsi { namespace xml {

  class Document
  {
    // ...
  public:
    ~Document();
    // ...
  }

} } // dsi::xml

Document.cpp

namespace dsi { namespace xml {

  // ...

  Document::~Document()
  {
    std::clock_t start = std::clock();

    // ...

    std::clock_t end = std::clock();

    // Speicherung/Ausgabe von (end - start) = 146ms
  }

  // ...

} } // dsi::xml

main.cpp

int main()
{
  char const* filePath = "C:/dev/projectxyz/xml-files/list.xml";

  std::clock_t firstStart = std::clock();

  {
    dsi::xml::Document doc;
    dsi::xml::Reader reader(doc);

    std::ifstream file(filePath);

    reader.read(file);
  }

  std::clock_t firstEnd = std::clock();

  // Ausgabe (firstEnd - firstStart) = 873ms

  std::clock_t secondStart = std::clock();

  dsi::xml::Document doc;

  {
    dsi::xml::Reader reader(doc);

    std::ifstream file(filePath);

    reader.read(file);
  }

  std::clock_t secondEnd = std::clock();

  // Ausgabe (secondEnd - secondStart) = 154ms

  return 0;
}

Der einzige Unterschied, zwischen den zwei Messungen in der main ist doch, dass kein Destruktor aufgerufen wird vom dsi::xml::Document Objekt. Aber wenn ich den Destruktor des dsi::xml::Document Objekt messe (die Klasse hat keine Basisklassen!), dann bekomme ich niemals diesen extremen Unterschied.

Kann mir das einer erklären? Und ich habe teilweise ähnliche Dinge, wenn ich Methodenaufrufe messe, von ausserhalb brauchen die eine extrem lange Zeit, innerhalb sind sie extrem schnell. Nur der Aufruf kann doch nicht so viel Zeitunterschied machen? Überseh ich etwas?

Grüssli

PS: Wenn mir jemand vernünftig den CodeAnalyst auf einer Intel-CPU mit Quellcode anzeige erklären könnte, dem wäre ich sehr dankbar

Ich brauch einen vernünftigen Profiler ...

Grüssli

CodeAnalyst von AMD einfach nicht klar komme

Ich habe den mehr oder wenig von Anfang an rein intuitiv bedienen können.
OK. Einen Haufen Funktionalität habe ich bis jetzt nicht gebraucht, aber die Engpässe + den Code dazu habe ich relativ schnell rausgefunden, wie ich die bekommen kann. (gibt glaube ich auch irgendwo ein paar Tuts dazu..)

Hat sich erledigt. Konnte es ... lösen ... oder ... naja, dieses Problem ist weg, dafür kamen sich 4 weitere Seltsamheiten zu Tage. Die ich zwar nicht begreife oder nicht ganz, aber nicht weiter wichtig sind und umgangen werden können.

Ich brauch einen vernünftigen Profiler ...

Grüssli

Was hast Du denn so alles in Deiner Document-Kasse drin? Nicht zufällig noch einen ganzen Satz an Strings oder gar Streams, die wieder mit zerstört werden? Das kannst Du nämlich im Dtor so nicht messen.

Document::~Document()
  {
    std::clock_t start = std::clock();

    // ...

    std::clock_t end = std::clock();

    // Speicherung/Ausgabe von (end - start) = 146ms
  } //!!!! hier werden noch alle möglichen nichtrivialen Objekte von Document zerstört !!!!

Tachyon schrieb:

Was hast Du denn so alles in Deiner Document-Kasse drin? Nicht zufällig noch einen ganzen Satz an Strings oder gar Streams, die wieder mit zerstört werden? Das kannst Du nämlich im Dtor so nicht messen.

Ne ne, es sind nur 3 Variablen darin:

NodeList_t m_nodeList;         // Wird innert 0ms aufgeräumt
Declaration* m_declaration;    // Wird gemessen, da per delete gelöscht.
DocumentHandler* m_docHandler; // Wird gemessen, da per delete gelöscht.

Aber wie ich schon sagte, das Problem hat sich erledigt. Hatte die Ausgabe der Ergebnisse zu früh angesetzt, wodurch eine Messung unterschlagen wurde.

Inzwischen kamen ganz andere Probleme auf. Wenn ich zum Beispiel zwei Codestücke vergleichen wollte (C1, C2), dann kam es ganz drauf an, in welcher Reihenfolge ich sie ausführte. C2 ging immer gleich lange, aber C1 ging deutlich schneller, wenn es vor C2 ausgeführt wurde, bzw. deutlich langsamer wenn danach. Dabei gibt es keinen Zusammenhang zwischen C1 und C2.

Und dann hab ich noch ein Problem entdeckt. Wenn ich die Klasse, welche sich in einer statischen Bibliothek befindet, selber im eigenen Programm implementiere und somit nicht die genau gleiche Klasse aus der Bibliothek verwende, dann läuft mein Testcode um satte 150ms schneller. Statt 200ms braucht es nur 50ms. Aber wahrscheinlich hat es etwas damit zu tun, dass der Compiler schlechter optimieren kann, wenn er die Klasse aus einer statischen Bibliothek beziehen muss, als wenn sie im eigenen Code vorhanden ist.

Naja, inzwischen weiss ich - oder glaube es zu wissen - , dass meine Bibliothek ein wenig länger braucht um ein XML Document zu erstellen, dafür deutlich schneller das Document wieder aufräumt, als TinyXML

Grüssli

Wenn ich mich recht erinnere, habe ich da ein wenig reingelesen und dann ging es.
(Obwohl ich irgendwie stark vermute, dass mir der Text nicht sehr viel gebracht hat und ich darum einfach selber ein wenig rumprobiert habe..)

http://developer.amd.com/documentation/articles/pages/1212200690.aspx

Wenn ich mich recht erinnere, habe ich da ein wenig reingelesen und dann ging es.
(Obwohl ich irgendwie stark vermute, dass mir der Text nicht sehr viel gebracht hat und ich darum einfach selber ein wenig rumprobiert habe..)

Hab den Link mal gespeichert. Allerdings, laut dem Titel, ist der Artikel für AMD Prozessoren. Aber hoffentlich werden auch Infos darin zu finden sein, welche ich für meine Intel-CPU verwenden kann.
Naja, lesen tue ich es erst später, habe aktuelle noch ein paar andere Dinge zu erledigen

Danke für den Link.

Grüssli

Meine Empfehlung:
http://www.glowcode.com

Nette Empfehlung ... nur kostet das Dinge genauso viel, wie andere Profiler. Und ich will mir so einen Profiler nicht leisten. 500$/€ ausgeben für etwas, was ich nur äusserst selten brauche und derzeit sowieso nicht für ein Produkt, aus welchem ich Geld beziehe. Sowas wäre ein wenig krank ...
Wenn ich dann mal soweit bin, denke ich aber eher, dass ich mir AQTime kaufe oder wenn ich das Geld aufbringen kann (aktuell 2'700€), dann vielleicht DevPartner Studio.

Da ist es schon irgendwie verlockend, die Dinger zu cracken ... bin doch nur ein mehr oder weniger Hobbyprogrammierer, der gerne ein wenig was lernen möchte in dem Bereich ^^"
Und nein, ich crack die Dinger nicht und bin auch nicht dran interessiert. Bevor jemand ausruft

Grüssli

Was ist denn mit Valgrind? Das hat doch auch einen Profiler.

Aber Valgrind ist nur Linux, soweit ich weiss. Und ich arbeite nunmal auf Windows mit Visual Studio

Fellhuhn schrieb:

gprof?

gprof geht soweit ich weiss nur mit dem gcc, bzw. g++. Ich arbeite aber, wie gesagt, mit Visual Studio.

Grüssli

Tachyon schrieb:

Was ist denn mit Valgrind? Das hat doch auch einen Profiler.

Aber Valgrind ist nur Linux, soweit ich weiss. Und ich arbeite nunmal auf Windows mit Visual Studio

Fellhuhn schrieb:

gprof?

gprof geht soweit ich weiss nur mit dem gcc, bzw. g++. Ich arbeite aber, wie gesagt, mit Visual Studio.

Grüssli

Vielleicht versuchst Du es trotzdem mal damit. Im Zweifelsfall mit VirtualBox unter Windows.

Vielleicht versuchst Du es trotzdem mal damit. Im Zweifelsfall mit VirtualBox unter Windows.

Witzbold
Dir ist schon klar, dass ich dann eine Ausführbare Datei erstelle für Linux und nicht mehr für Windows? Da muss ich dann auch einen anderen Compiler verwenden. Kannst mir gleich vorschlagen, dass ich künftig auf Linux mit Code::Blocks entwickeln soll, kommt auf das gleiche raus

Fellhuhn schrieb:

Dann schließe ich daraus vollkommen logisch und niemand kann mir da aufgrund meiner perfekten Argumentation widersprechen: Visual Studio ist schuld. SCNR

Du meinst es nicht ernst, aber grundsätzlich hast du recht! Visual Studio ist halt eine IDE für "Profis", bzw. für Firmen. Deshalb sind auch alle Add-Ons und co entsprechend auf solche Kunden ausgerichtet. Was dazu führt, dass die Dinger was kosten, so dass sich eine Firma sowas leisten kann, ein Hobbyprogrammierer aber Mühe hat.

Ich könnte natürlich auf Code::Blocks mit dem g++ entwickeln. Dann könnte ich gprof nehmen, welcher in Code::Blocks sogar ein Interface hat. Nur mir persönlich gefällt Code::Blocks nicht so richtig. Vor allem VAX würde ich auf Code::Blocks extrem vermissen ...

Grüssli