4. Optimierung bzw Analyse eines Compilevorgangs mit dem MS ViStu 6.0 - wie?

Optimierung bzw Analyse eines Compilevorgangs mit dem MS ViStu 6.0 - wie?

  • F

    Hallo,
    ich bin seit ein paar Wochen in ein Projekt "geraten", in dem alles etwas chaotischer ist... Es handelt sich um ein verteiltes System, Corba und der Grossteil laeuft in Java, ich sitze jedoch an einem C++ Modul. Das ganze wird mit MSVC 6.0 kompiliert. Es gibt Mocs fuer die Ausgaenge zu Java ueber Corba um ein paar Tests zu ermoeglichen.

    Das Problem ist, es braucht knappe 6 bis 8 Stunden zum kompilieren! Dabei liegt codemaessig schon vieles im Argen, da sich hier die Technik "copy & paste" sehr eingebuergert hat, es existiert sehr viel "Ritueller Code und mindestens schon mal 10 Sicherheitskopien jeder Zeile in sich selber. Gut, ein Refactoring des Codes ist sicherlich schwer noetig. Ob ich dazu faehig bin bezweifle ich. Momentan wuerde mich aber auch erstmal mehr interessieren, ob ich den Kompiliervorgang irgendwie optimieren kann.

    - Gibt es beim MS ViStu Moeglichkeiten, Tools oder Plugins um zu erkennen WO es denn gerade kompiliert, bzw wo die meisste Compilezeit abfaellt?

    - Welche Moeglichkeiten habe ich direkt im MS ViStu evtl Dinge abzuschalten? Gibt es da so generelle Punkte die ich mal kontrollieren koennte - schliesslich will ich ja nicht immer das komplette System neubauen.. wenn es nicht unbedingt noetig ist?

    - Kennt jemand evtl Links die mir da weiterhelfen koennen um den Compilevorgang zu tunen (von Seiten des Compilers)?

    Danke.

    0

  • MSVC 6 ist einer der schnellsten C++ Compiler, von daher fällt die Möglichkeit "Compiler wechseln" schonmal flach.

    Was nach meiner Erfahrung sicher am meisten bringt: Precompiled Headers verwenden. Dazu muss aber jedes (bzw. fast jedes) C++ File als erstes ein ganz bestimmtes Header-File inkludieren. Wenn das in einem Projekt noch nicht so ist, dann kann es u.U. auch recht lange dauern das umzubauen -- je nachdem wie viele Files es gibt, etc.

    0
  • V

    hustbaer schrieb:

    MSVC 6 ist einer der schnellsten C++ Compiler, von daher fällt die Möglichkeit "Compiler wechseln" schonmal flach.

    den eindruck habe ich auch.

    precompiled headers haben bei mir nie viel gebracht. konsquentes einsparen von include-zeilen brachte bei mir immer am meisten, insbesondere der <windows.h>. gerne auch mit sleep.h: void sleep(int ms); und sleep.cpp: #include <windows.h> void sleep(int ms){Sleep(ms;}, um ein paar dateien von der windows.h befreien zu können und in der annahme, daß schlafen nicht performancekritisch ist.

    0
  • Mod

    volkard schrieb:

    precompiled headers haben bei mir nie viel gebracht. konsquentes einsparen von include-zeilen brachte bei mir immer am meisten, insbesondere der <windows.h>. gerne auch mit sleep.h: void sleep(int ms); und sleep.cpp: #include <windows.h> void sleep(int ms){Sleep(ms;}, um ein paar dateien von der windows.h befreien zu können und in der annahme, daß schlafen nicht performancekritisch ist.

    Bei meinen Projekten verdoppelt sich die Compilezeit ohne Precompiled Header.
    Bist Du sicher, dass #include <windows.h> wirklich soviel ausmacht, wenn die windows.h schon im Precompiled Header steht? Ich kann es mir kaum vorstellen...

    0
  • V

    Martin Richter schrieb:

    Bei meinen Projekten verdoppelt sich die Compilezeit ohne Precompiled Header.
    Bist Du sicher, dass #include <windows.h> wirklich soviel ausmacht, wenn die windows.h schon im Precompiled Header steht? Ich kann es mir kaum vorstellen...

    ja, bin sicher. mit dem msvc6. beim borland hatten precompiled headers den tollen effekt. bei ms hab ich's nie hingekriegt. anscheinend muß man einen anderen programmirstil als meinen pflegen, damit die einstellung großen effekt zeigt. ich habe nur kleine projekte ausgemessen, nicht mehr als 50 files und sehr sparsames inkludieren. bei größeren sind die pch einfach eingeschaltet, um andere programmierer nicht zu verwirren.
    freut mich zu hören, daß die precompiled headers doch wirken.

    0
  • Mod

    Ich habe eben einen Test an einem SDI Projekt gemacht, dass ich einfach mit dem Wizard erzeugt habe.

    Nachdem ich einen vollen Rebuild gemacht habe, wurden alle .OBJ Dateien entfernt außer der stdafx.obj und pch.

    - Build mit pch Dateien < 1 Sekunden
    - Build ohne pch Dateien ca. 5 Sekunden

    Ich kann mir nicht vorstellen, dass es bei Dir kaum etwas ausmacht.

    0

  • Bei den Projekten bei uns in der Firma sehen wir auch Verbesserungen die *weit* über Faktor 2 liegen, eher Richtung 5-10, und das selbst bei vollen Rebuilds (wo also auch das PCH File neu erstellt wird).

    Natürlich könnte man das zugunsten der "ohne PCH" Variante verbessern, indem man viel mit fwd.-declarations arbeitet und "sinnlose" include Zeilen sucht und entfernt, aber das ist einfach ziemlich viel Aufwand -- PCH einschalten ist da weit einfacher, vor allem wenn man ein Projekt schon von Beginn an so schreibt.

    Was *nicht* wirklich funktioniert ist die Option "automatisch verwenden" (die in späteren Studio Versionen auch entfernt wurde -- ab 2005 glaube ich). Soll heissen: man muss das PCH Header File immer mit Namen angeben, sonst bringt es nix.

    0
  • V

    hustbaer schrieb:

    Was *nicht* wirklich funktioniert ist die Option "automatisch verwenden"

    daran kann es gelegen haben.

    0
Anmelden zum Antworten