VS2005 Release Version wirklich Release geeignet?
-
Dravere schrieb:
Mein Problem liegt daran, dass eben per Default eine Release Version auch ein PDB aufweist. Auch wenn es nur symbolischen Charackter hat, so ist es doch vorhanden und meiner Meinung nach überflüssig.
Es ist endlich mal sinnvoll, dass per default auch die Release eine PDB hat! Wenn Du einen Abstutz in Deinem Programm hast und ein MiniDump bekommst, kannst Du nämlich damit genau die Codezeile finden, welche den Absturz verursacht hat. ALso total sinnvoll.
Und die erzeugung/existenz einer PDB-Datei hat rein gar nicht mit der compilierten EXE und deren Geschwindigkeit zu tun.Dravere schrieb:
Und wenn ich sehe, dass der CFF Explorer 70-80% meiner Release EXE Version wegwerfen kann und das ganze trotzdem noch läuft, ohne einen Geschwindigkeitsverlust, dann frag ich mich, ob es noch sonstige solche Defaults gibt, welche man aber eigentlich abschalten könnte.
Mit der Geschwindigkeit hat das erzeugen einer PDB-Datei nichts zu tun. In der EXE wird nur ein Eintrag hinzugefügt, dass es eine gibt.
Wenn Du eine kleine EXE haben willst, dann
- verwende *keine* CRT
- verwende nur ein Segment
- aligne das Segment mit 16 ByteDamit bekommst Du ein "Hello world" mit 688 Bytes hin.
http://blog.kalmbach-software.de/2008/02/02/smallest-application-size-for-win32-console-application/
-
Jochen Kalmbach schrieb:
Es ist endlich mal sinnvoll, dass per default auch die Release eine PDB hat! Wenn Du einen Abstutz in Deinem Programm hast und ein MiniDump bekommst, kannst Du nämlich damit genau die Codezeile finden, welche den Absturz verursacht hat. ALso total sinnvoll.
Extrem sinnvoll, wenn die PDB in eine externe Datei kommt, welche natürlich mit dem Programm nicht ausgeliefert wird.
Es mag sinnvoll sein, für den persönlichen Test, aber wenn die Sache beim User ist, bringt es nichts. Es steht dann dort höchsten ein Pfad von meinem System drin, was man vielleicht unter gewissen Umständen nicht möchte.Jochen Kalmbach schrieb:
Und die erzeugung/existenz einer PDB-Datei hat rein gar nicht mit der compilierten EXE und deren Geschwindigkeit zu tun.
Zeige mir eine Stelle, wo ich sowas behauptet habe. Das war nur ein Beispiel, wo ich fand, dass etwas erzeugt wird, was gar nicht gebraucht wird. Es geht hier weder um Geschwindigkeit noch um Grösse einer Datei. Das sind alles Beispiele. Es geht um Optionen, welche man getrost abschalten kann, weil sie unsinnig sind oder gar vielleicht noch eine Beschleunigung verursachen, aber das muss nicht sein.
Jochen Kalmbach schrieb:
Dravere schrieb:
Und wenn ich sehe, dass der CFF Explorer 70-80% meiner Release EXE Version wegwerfen kann und das ganze trotzdem noch läuft, ohne einen Geschwindigkeitsverlust, dann frag ich mich, ob es noch sonstige solche Defaults gibt, welche man aber eigentlich abschalten könnte.
Mit der Geschwindigkeit hat das erzeugen einer PDB-Datei nichts zu tun. In der EXE wird nur ein Eintrag hinzugefügt, dass es eine gibt.
Den Zusammenhang, zwischen deinem Satz und dem meinigem musst du mir hier aber mal erklären.
Jochen Kalmbach schrieb:
Wenn Du eine kleine EXE haben willst, dann...
Habe ich das gefragt? Ich habe mich nur gefragt, wie der CFF Explorer das hinbekommt. Der verändert am eigentlichen Code, soweit ich weiss nichts. Der bildet nur die PE-Header nochmals neu. Und anscheinend deutlich sinnvoller und kleiner.
Ok, die 80-70% sind halt auch bei einem nicht all zu grossen Programm. Es war glaub ich nur eine 300kb Datei, aber trotzdem, das ist schon eine beachtliche Menge, welche da weggenommen wurde. Und wenn man bedenkt, dass das nur irgendwelche Headers sein sollen. Respekt!
Aber wieso kann der Compiler das zeug nicht gleich wegnehmen?Jochen Kalmbach schrieb:
Damit bekommst Du ein "Hello world" mit 688 Bytes hin.
http://blog.kalmbach-software.de/2008/02/02/smallest-application-size-for-win32-console-application/Guter Artikel, nur nicht das was ich suche
Grüssli
-
Dravere schrieb:
Extrem sinnvoll, wenn die PDB in eine externe Datei kommt, welche natürlich mit dem Programm nicht ausgeliefert wird.
Ja, ganz genau. Die eingebtteten Debug-Infos gibt es schon seit VS2002 nicht mehr! Diese gab es nur bis zu VC6.
Dravere schrieb:
Es geht um Optionen, welche man getrost abschalten kann, weil sie unsinnig sind
Das ist alles reine Geschmackssache. Per default ist *alles* Sinnvoll, was im Release auch per Default aktiviert ist.
Ob *Du* dies allerdings als Sinnvoll erachtest, ist dir selber überlassen.
Dravere schrieb:
Jochen Kalmbach schrieb:
Dravere schrieb:
ohne einen Geschwindigkeitsverlust
Mit der Geschwindigkeit hat das erzeugen einer PDB-Datei nichts zu tun. In der EXE wird nur ein Eintrag hinzugefügt, dass es eine gibt.
Den Zusammenhang, zwischen deinem Satz und dem meinigem musst du mir hier aber mal erklären.
Dravere schrieb:
Ich habe mich nur gefragt, wie der CFF Explorer das hinbekommt.
Dazu kannst Du einfach die Doku lesen. Er entfernt Dinge, die zur *Ausführung* nicht gebraucht werden!
Nacher kannst Du allerdings z.B. keine Fehleranalyse mehr betreiben... aber das willst Du ja eh nicht.
Dravere schrieb:
Der verändert am eigentlichen Code, soweit ich weiss nichts.
Genau. Ausser dass er ihn optional auch noch komprimieren kann (soweit ich das verstanden habe).
Dravere schrieb:
Der bildet nur die PE-Header nochmals neu. Und anscheinend deutlich sinnvoller und kleiner.
Ob dies "sinnvoler" ist, musst jeder für sich selber und seine Anwendung bestimmen.
Dravere schrieb:
Aber wieso kann der Compiler das zeug nicht gleich wegnehmen?
Weil es per Default aus MS-Sicht nicht Sinnvoll ist.
Besorg Dir halt einen anderen Compiler, der es per default auch weglässt.Wie gesagt: Dir geht es *nur* um die größe der EXE, somit kannst Du meine Einstellungen in meinem Blog verwenden und bekommst eine sehr kleine EXE hin, wo alle *unnötigen* Dinge schon entfernt sind...
-
Jochen Kalmbach schrieb:
Dravere schrieb:
Extrem sinnvoll, wenn die PDB in eine externe Datei kommt, welche natürlich mit dem Programm nicht ausgeliefert wird.
Ja, ganz genau. Die eingebtteten Debug-Infos gibt es schon seit VS2002 nicht mehr! Diese gab es nur bis zu VC6.
Super ...
Ich habe mich ja eigentlich nun schon längstens geoutet, dass ich ein N00B in dem Bereich bin. Also eigentlich so gut wie null Ahnung.
Ich sehe, dass Debug Informationen erstellt werden und diese extern in einer Datei abgespeichert werden. In der EXE wird dazu ein Pfad gespeichert, welcher auf diese Datei verweist. Diese externe Datei mit Informationen, wird aber weder weitergegeben, noch wird der Pfad in der EXE angepasst.
Ein Kunde, welcher die EXE bekommt, hat in meinen N00B Augen, überhaupt gar keine Verwendung für diesen Pfad. Und was lieferst du mir als Antwort?Es ist Standard seit VS2002.
Jochen Kalmbach schrieb:
Dravere schrieb:
Jochen Kalmbach schrieb:
Dravere schrieb:
ohne einen Geschwindigkeitsverlust
Mit der Geschwindigkeit hat das erzeugen einer PDB-Datei nichts zu tun. In der EXE wird nur ein Eintrag hinzugefügt, dass es eine gibt.
Den Zusammenhang, zwischen deinem Satz und dem meinigem musst du mir hier aber mal erklären.
Und mein Satz lautete:
Und wenn ich sehe, dass der CFF Explorer 70-80% meiner Release EXE Version wegwerfen kann und das ganze trotzdem noch läuft, ohne einen Geschwindigkeitsverlust, dann frag ich mich, ob es noch sonstige solche Defaults gibt, welche man aber eigentlich abschalten könnte.Jetzt sag mir mal, wo ich da gesagt habe, dass die PDB Datei zu einem Geschwindigkeitsverlust führt? Oder liest du nur die 3 Wörter, welche dir in meinem Satz gefallen?
Die PDB Datei wird nicht einmal Ansatzweise erwähnt!Jochen Kalmbach schrieb:
Nacher kannst Du allerdings z.B. keine Fehleranalyse mehr betreiben... aber das willst Du ja eh nicht.
Danke für die Unterstellung. Doch, die Fehleranalyse will ich, nur seh ich den Sinn dahinter nicht, wie das funktionieren soll, wenn die dazu notwendige Datei, sowieso nicht dabei ist! Das kann ja nicht funktionieren! Daher unnötig!
Jochen Kalmbach schrieb:
Wie gesagt: Dir geht es *nur* um die größe der EXE, somit kannst Du meine Einstellungen in meinem Blog verwenden und bekommst eine sehr kleine EXE hin, wo alle *unnötigen* Dinge schon entfernt sind...
Ich finde es schön, wie du weisst, was ICH will ...
Grüssli
-
Also zu den Debug infos.
Der Kunde soll auch keine Debug durchführen.
Nur weil du nicht weißt wie es geht wenn dein Programm crasht heißt das noch nicht das man es default abschalten sollte.
Jochen sprach von einem Dump der erstellt wird. Mit diesem kannst DU dann Debug machen.
-
Dravere schrieb:
Zudem habe ich beim rumstöbern entdeckt, dass man SSE/2 einschalten kann. Das gab bei mir eine Beschleunigung an gewissen Stellen von bis zu 200ms.
Es gibt übrigens immer noch Prozessoren, die kein SSE2 können. Der Compiler tut also ganz gut daran, die Aktivierung dem Programmierer zu überlassen.
Dravere schrieb:
Extrem sinnvoll, wenn die PDB in eine externe Datei kommt, welche natürlich mit dem Programm nicht ausgeliefert wird.
Es mag sinnvoll sein, für den persönlichen Test, aber wenn die Sache beim User ist, bringt es nichts. Es steht dann dort höchsten ein Pfad von meinem System drin, was man vielleicht unter gewissen Umständen nicht möchte.Dann deaktiviere halt die Option in den Linkereinstellungen, dass Debuginfos eingebunden werden sollen. Dann dürfte auch der PDB-Eintrag in der EXE verschwinden.
Dravere schrieb:
Habe ich das gefragt? Ich habe mich nur gefragt, wie der CFF Explorer das hinbekommt. Der verändert am eigentlichen Code, soweit ich weiss nichts. Der bildet nur die PE-Header nochmals neu. Und anscheinend deutlich sinnvoller und kleiner.
Ok, die 80-70% sind halt auch bei einem nicht all zu grossen Programm. Es war glaub ich nur eine 300kb Datei, aber trotzdem, das ist schon eine beachtliche Menge, welche da weggenommen wurde. Und wenn man bedenkt, dass das nur irgendwelche Headers sein sollen. Respekt!
Aber wieso kann der Compiler das zeug nicht gleich wegnehmen?Das hat vermutlich mit dem integrierten UPX Utility zu tun. Das hat aber nichts mit überflüssigen Informationen in der EXE zu tun, das ist ganz normale Laufzeitkomprimierung. Nicht mehr und nicht weniger.
-
Dravere schrieb:
Es ist Standard seit VS2002.
Nein! Wenn Du eine PDB erzeugt hast, dann ist dieses Verfahren schon immer Standard gewesen!
Also auch zu VC6 Zeiten und IMHO auch wurd dieser Pfad schon in VC4 Zeiten bei PDB Dateien in die EXE eingetragen!
-
Dravere schrieb:
Ein Kunde, welcher die EXE bekommt, hat in meinen N00B Augen, überhaupt gar keine Verwendung für diesen Pfad.
Natürlich hat der *Kunde* keine Verwendung dafür. Aber dafür *Du*, wenn Du einen MiniDump debuggen willst....
Dravere schrieb:
Danke für die Unterstellung. Doch, die Fehleranalyse will ich, nur seh ich den Sinn dahinter nicht, wie das funktionieren soll, wenn die dazu notwendige Datei, sowieso nicht dabei ist! Das kann ja nicht funktionieren! Daher unnötig!
Wenn Du es nicht verstehst, heisst es noch lange nicht, dass es nicht geht.
-
Martin Richter schrieb:
Jochen Kalmbach schrieb:
Es ist Standard seit VS2002.
Nein! Wenn Du eine PDB erzeugt hast, dann ist dieses Verfahren schon immer Standard gewesen!
Ich wollte nur damit sagen, dass man ab VS2002 keine Debug-Infos mehr einbetten *kann* sondern nur noch PDB-Dateien erstellen kann! ALso keine CV-Symbole mehr in der EXE.
Per default war es eben in VC6 nicht aktiviert... weder PDB noch CV/COFF-Symbole im Release.
-
*Kopf schüttelt*
Ich bekomme noch die Krise.Wie kann man so neben dem Thema durchantworten? Der einzige einigermassen sinnvolle Beitrag bisher war von Unix-Tom. Der erste, welcher mir etwas erklärt und nicht nur unterstellt oder von irgendwelchen Standards erzählt hat, nach welchen ich gar nie gefragt habe und die auch gar nichts erklären.
Nehmen wir als B E I S P I E L (denn das war es von Anfang an!), die PDB Datei:
Wieso konntet ihr mir nicht einfach sagen, wie man diese einsetzt?
Man hätte zum Beispiel sagen können:
"Nein es ist sinnvoll die PDB Datei zu erzeugen, da der Kunde die MiniDumps dir zurück schicken kann und du mit der PDB Datei dann debuggen kannst. Für weitere Informationen, schau dir folgenden Link an oder suche nach Stichwort xyz ..."Stattdessen hat man mir folgende Antwort gegeben:
Es ist Standard.Wenn etwas Standard ist, heisst das noch LANGE nicht, dass es auch sinnvoll ist. Und vor allem erklärt es nichts. Man bekommt sogar eher das Gefühl, dass der andere einem nur veräppeln will oder den Beitrag gar nicht gelesen hat.
... *sich beruhigt ... ein und ausatmet* ...
Daher vielleicht nochmals meine Frage von ganz am Anfang. Gibt es irgendwo ein Dokument oder eine Anleitung, welche erklärt, wie man die Optionen des Compilers so anspassen kann, wie man es gerne möchte. Und vor allem, welche die Compiler Optionen etwas ausführlicher behandeln, als nur die sehr kurzen Beschreibungen in der MSDN (zumindest die, welche ich gefunden habe, waren sehr knapp).
Die eben zum Beispiel den Nutzen von so einer PDB Datei erklären. Aber es gibt da sicherlich auch noch andere Dinge. Und natürlich in erster Linie auf die Release version abgezielt.Und vielleicht gibt es ja auch noch irgendwo ein Dokument zu diesem "UPX". Zum Beispiel, wieso der Compiler sowas nicht gleich selber machen kann, was auch immer das Ding macht?
Grüssli
-
Du bist schon früher auf Minidumps von Jochen hingewiesen worden (Posting gestern 19:11). Unix-Tom hat es nur noch mal wiederholt!
Die MSDN ist nach meinem Dafürhalten ziemlich ergiebig. Das Problem ist einfach, dass viele Dinge ineinandergreifen.
Warum muss bei der Option zur Erzeugung von Debug Infos etwas zu Crashdumps stehen? Das eine hat primär mit dem anderen nichts zu tun!
Warum müsste bei Optionen zu Static Link etwas zur Auslieferungsproblemtik stehen?C++ ist eben ein weites sehr, sehr komplexes Thema.
Die Frage ist einfach: Was willst Du eigentlich?
Sich über den Sinn und Zwecke jedes Schalter erkundigen?
Dein Programm besser machen?Zum Thema Standard: Ich lasse mittlerweile fast von allen Compiler Schaltern die Finger und belasse es beim "Standard"! Warum auch nicht. Ich kenne "fast" jeden Schalter aber meine Streifzüge durch diesen Dschnugel haben ergeben:
Beschäftigung damit lohnt sich nur, wenn man ein spezielles Problem damit lösen kann! Ansonsten lebt man prima mit dem Standard.Was soll übriends daran besser sein an diesen EXE "Optimierungen", die Laufzeitmässig nict bringen? Warum sollte man ein Programm also so optimieren?
Es gibt weitaus effektivere Optimierungen, die nur die wenigsten Leute verwenden, z.B. Whole Program Optimization.
-
Martin Richter schrieb:
Du bist schon früher auf Minidumps von Jochen hingewiesen worden (Posting gestern 19:11). Unix-Tom hat es nur noch mal wiederholt!
Hingewiesen, ja, aber nicht erklärt.
Und ich habe deshalb dann auch meine Zweifel daran geäussert.Martin Richter schrieb:
Die Frage ist einfach: Was willst Du eigentlich?
Sich über den Sinn und Zwecke jedes Schalter erkundigen?Genau das. Aber am besten halt in die Richtung einer release Version orientiert. Ich möchte gerne wissen, was mein Compiler da eigentlich alles in die EXE packt, wie er das macht und wie man das Zeug steuern kann. Und halt eben dann über Sinn und Unsinn, bzw. den Zweck der Schalter.
Martin Richter schrieb:
Dein Programm besser machen?
Ich denke ich kann meine Programme eher besser machen, wenn ich besser programmiere, zumindest derzeit ist das wohl noch so. Gerade letztens den Sinn von einem Buffer zwischen einem std::istream und einem Parser entdeckt. Eine ganze Sekunde schlussendlich eingespart (von insgesamt 2)
Martin Richter schrieb:
Beschäftigung damit lohnt sich nur, wenn man ein spezielles Problem damit lösen kann! Ansonsten lebt man prima mit dem Standard.
Wenn man auch versteht, wie der Standard aussieht und was es sonst noch so gibt
Martin Richter schrieb:
Was soll übriends daran besser sein an diesen EXE "Optimierungen", die Laufzeitmässig nict bringen? Warum sollte man ein Programm also so optimieren?
Ich sage es mal so (Ist glaub ich ein Zitat, weiss aber nicht von wem):
Eine Maschine ist nicht dann perfekt, wenn man nichts mehr dazufügen kann, sondern wenn man nichts mehr weglassen kann.Grüssli
-
Dravere schrieb:
Wieso konntet ihr mir nicht einfach sagen, wie man diese einsetzt?
Doppel-Klick auf die dmp-Datei; und F5 drücken.
