Du erzeugst bei nummer 2 ein neues objekt, und ich gehe davon aus dass dieses objekt mehr speicher als 2 int variablen verbraucht(ich weiß es nicht, ich gehe bloß davon aus)
Und weil das Rectangle am ende eine eigne kopie der zahlen anfertigt (ob bloß als int oder als size ist egal) gibst du mit dem neuen Objekt deinem Garbage Collector bloß mehr arbeit.
ich würd das erste nehmen

Ich erlaube mir mal, zu vermuten, dass das überhaupt keinen Unterschied macht.
Wahrscheinlich wird das Ganze intern sowieso so behandelt:Wobei man bei letzterem gleich eine Referenz zu einem existierenden Point/Size-Objekt übergeben könnte, was dann auch wieder Speicher sparen würde...

Es ist definitiv so, dass beide Verfahren denselben Speicher benötigen. Die Auswahl der Methode sollte sich nach den vorhandenen Daten richten.
In Deinem Fall ist es definitiv egal.

Nein ein rectangle speichert die werte als integrale oder zumindest als eigne klasse, eine eigne klasse zu instanzieren würde nur arbeit für den gb machen

Niko Ortner schrieb:

Ist es einfacher/sinnvoller/perfomanter... zu verwenden?

Ist piepegal.
Nimm das was weniger umständlich hinzuschreiben ist.

in deinem Beispiel ist das erste schneller, da es ein Objekt weniger erzeugt...
intern sieht New bei der Rectangle-Klasse nämlich so aus:

Rectangle, Point, Size, ... sind Strukturen und keine Klassen, herrjeh.
Himmelweiter Unterschied.

Ob du nun in einer Struktur definierst welche Variablen wo liegen oder in der Signatur der Sub/Function ist irrelevant. Zuweisen musst du die Werte so oder so, ergo 0 Unterschied.

Relevanter ist da eher das interne Handling, welches sich aber nahezu vernachlässigen lässt.

Performanter wäre es die Point/Size/Rect's zu cachen (sprich in der Klasse / dem Control zu definieren) und dann nur bei Bedarf zu verändern (in OnResize z. B.). Sofern möglich.

Herrjeh ich hab recht
Strukturen und Klassen: Himmelweiter unterschied?!
Eigentlich überhaupt nicht, der Hauptunterschied besteht darin, dass Klassen Referenztypen sind und Strukturen sind Wertetypen, somt sind Klassen für den Globalen/langlebigen Gebrauch da...

Aber der Unterschied zwischen 1 und 2 bleibt weiterhin bestehen - wenn auch gering, um den Wert nur bei bedarf zu ändern braucht man ja auch nicht gleich eine neue Klasse zu machen...

jvbsl schrieb:

Herrjeh ich hab recht

Nein, hast du nicht.
Lies mal das hier: msdn.microsoft.com/de-de/library/2hkbth2a(v=vs.80).aspx
Oder auch das hier: msdn.microsoft.com/en-us/library/aa289521(v=vs.71).aspx

Wichtigster Punkt: "Strukturen verwenden Stapelzuweisung; Klassen verwenden Heapzuweisung."
Erklärung:

Reference types are managed on the heap, value types on the stack. There is a performance overhead for heap allocation, object access, and garbage collection, so class instances are less efficient than structure instances in this respect. The speed difference, which depends on many factors such as platform, loading, and data size, can range from unnoticeable to enormous.

Edit by Manschula: Ein Vollzitat des vorhergehenden Beitrags ist nun wirklich unnötig --> Vollzitat gekürzt

Hab ich weiterhin:

jvbsl schrieb:

der Hauptunterschied besteht darin, dass Klassen Referenztypen sind und Strukturen sind

So groß ist der Unterschied nicht...

egal ob klasse oder struktur, der pc kommt mit normalen variablen am besten zurecht, was in diesem fall ein int wäre

wie wärs so?

Niko Ortner schrieb:

Werden aber bei (um das im ersten Post genannte Beispiel nochmal zu verwenden) New Rectangle(DirectCast(sender, Button).Location.X, DirectCast(sender, Button).Location.Y, 5, 5)

:?: im ersten Post steht nix von Button

nicht auch jedesmal neue Instanzen eines Buttons erstellt (also hier zwei mal)?

Sehr daneben. DirectCast erstellt doch keine neue Button-Instanz!

WarFlys Schreibweise is vlt. bisserl leserlicher, weil die Zeile nicht so elend lang ist. Nur wasses soll, den tmpButton auf Nothing zu setzen?

idioten absicherung, nicht das jm auf die idee kommt danach noch tmpButton.Dispose zu schreiben.

Außerdem habe ich mir das so angewöhnt (wegen obj-c programmierung)

Warfley schrieb:

nicht das jm auf die idee kommt danach noch tmpButton.Dispose zu schreiben.

Kommt das öfter vor bei euch, dass jm XY.Dispose iwo in einen Code reinschreibt, dener findet?

ErfinderDesRades schrieb:

Ist piepegal.
Nimm das was weniger umständlich hinzuschreiben ist.

Wir müssen echt nicht die einzelnen Bytes zählen, die in einer Methode alloziiert werden (und anschließend natürlich sofort wieder frei sind).

Und Directcast ist zwar ein grauenhaft unleserliches Schlüsselwort, aber gehört zu den schnellsten Operationen, die ausgeführt werden. Ich bin mir nicht sicher, aber vlt. löstes sich bei Übersetzung sogar in Nichts auf.
Also dasses nur eine Anweisung an den Compiler ist: "Betrachte dieses "sender"-Token einfach mal nicht als vom Typ Object, sondern als vom Typ Button".

Ich sachs nochma: Es ist unvergleichlich viel wichtiger, dass Code gut lesbar ist, als dass da 10 Bytes über einen Zeitraum von 1000 Takten eingespart werden oder sowas.
Oder ob die Methode mw. auch um 1000 Takte länger dauert.

Interessiert nicht die Bohne.

Ich habe ja nur rein von der Theorie geredet
Und es ist richtig DirectCast ist wirklich sehr schnell, da hier beim Objekt nur geschaut wird, ob es von dem Typen erbt, in den gecastet werden soll, andernfalls bekommt man sowieso einen Fehler...
Bei CType wird z.B. geguckt ob es möglich ist zu konvertieren, was somit viel mehr Zeit in Anspruch nimmt...