Laden...

.NET Assembly wird nicht optimiert

Erstellt von userid4106 vor 12 Jahren Letzter Beitrag vor 12 Jahren 1.988 Views
U
userid4106 Themenstarter:in
457 Beiträge seit 2006
vor 12 Jahren
.NET Assembly wird nicht optimiert

Hi,

heute sind HDD`s im TB ja schon normal. Platz hin oder her, lassen wir das trotzdem mal bei Seite.

Ich habe eine Anwendung die ich im Release Modus kompiliere. Nun finde ich aber plötzlich Methoden in der kompilierten Anwendung, die gar nicht gebraucht werden(also sie werden erst später(NICHT ZUR LAUFZEIT!) gebraucht).

Jetzt sollte ich doch eigentlich denken, dass der Compiler, der scheinbar nicht so klug wie der C++ Compiler ist, das wegoptimieren sollte. Tut er aber nicht. Und das frisst eben Platz. Die Anwendung ist ca 1MB groß und ich bin mir sicher, dass wenn ich mal selber Hand anlegen würde, ich so bei 900KB ankommen würde.

Außerdem werden ja scheinbar auch Methodennamen komplett so gespeichert wie ich sie auch bennant habe. Die sind ziemlich lang und das frisst auch Platz.

Gibt es da einen besonderen Trick oder einen weiteren Parameter auf der cmd umd das optimieren zu beeinflussen?

1.378 Beiträge seit 2006
vor 12 Jahren

OMG und WTF?

Warum sollten Methoden wegoptimiert werden? Code optimieren != aufräumen. Dafür ist der Entwickler schon selber zuständig. Wie sollen den zur Laufzeit eingelesene Assemblies funktionieren, wenn alle Methoden vom Compiler wegoptmiert wurden weil sie zur Compile-Time keiner gebraucht hat?

Und sich wegen Methodennamen und 100kb ernsthafte Gedanken machen? Sorry aber hast du sonst nichts zu tun?

Lg, XXX

6.911 Beiträge seit 2009
vor 12 Jahren

Hallo,

wie hast du das denn geprüft - mit dem Reflektor? Dann siehst du nur den IL der nicht ausgeführt wird, sondern vom JITer/NGen noch in Maschinencode übersetzt wird und dieser wird ausgeführt. Dort werden dann auch die Optimierungen durchgeführt.

Außerdem werden ja scheinbar auch Methodennamen komplett so gespeichert wie ich sie auch bennant habe.

Das ist im IL-Code ja ziemlich wurscht. Auf Maschinenebene gibts es nur jumps 😉

Nun finde ich aber plötzlich Methoden in der kompilierten Anwendung, die gar nicht gebraucht werden(also sie werden erst später(NICHT ZUR LAUFZEIT!) gebraucht).

Wenn sie später gebraucht werden dann ist doch gut dass sie drin sind. Zu beachten ist auch dass eine EXE "als DLL" verwendet werden kann. Beides sind nämlich Assemblies und somit weiß der Compiler ja nicht ob diese (public) Methode in einer eventuell referenzierenden Assembly benötigt wird.

Gibt es da einen besonderen Trick oder einen weiteren Parameter auf der cmd umd das optimieren zu beeinflussen?

In der Commandozeile mit dem Compiler "asm" arbeiten 😉

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

5.742 Beiträge seit 2007
vor 12 Jahren

Hallo Second Sun,

es gibt ein paar Tools, um sogenannten "toten Code" (engl. "dead code") zu finden - google einfach mal danach.
Manche von denen fügen IMHO sogar spezielle Instruktionen in den Code ein, um so zu prüfen, ob er tatsächlich ausgeführt wird.

Der Compiler ist dazu nicht in der Lage - sonst wäre ja Reflection nicht wirklich möglich bzw. die Komplexität (und damit die Fehleranfälligkeit) des Compilers würde sehr stark ansteigen.

Und ja: Eine manuelle Eliminierung von totem Code ist sowieso besser - dann wird der Code an sich deutlich einfacher zu verstehen.

2.891 Beiträge seit 2004
vor 12 Jahren

Es gibt auch diverse Obfuskatoren, die "hauptamtlich" die Methodennamen verkürzen und auch nicht benutzten Code entfernen können.

5.657 Beiträge seit 2006
vor 12 Jahren

Moment, man kann doch nicht davon ausgehen, daß unbenutzte Methoden wegoptimiert werden. Das machen auch Obfuscatoren nur, wenn man es ihnen explizit sagt. Denn der Compiler weiß ja nicht, wer die Assemblys benutzt und wer welche Methoden aufruft. Zumindest die als Public deklarierten Methoden/Properties/Klassen dürften unter keinen Umständen verlorengehen!

Weeks of programming can save you hours of planning

0
767 Beiträge seit 2005
vor 12 Jahren

ich hab 8GB im Firmen PC - das ist zugegebenermassen etwas mehr als der Standard Benutzer hat - nämlich 8000x so viel wie dein Programm braucht... und du machst dir Sorgen um 100k die der Compiler sparen könnte?

loop:
btst #6,$bfe001
bne.s loop
rts