Wpf Arbeitsspeicherauslastung

Hallöchen,

keine Ahnung ob das Thema schon mal aufgekommen ist. Habe auf jeden Fall wild gegooglet wahrscheinlich unter falschen Suchkriterien.
Entschuldigt wenn es eine altbekannte Frage ist.

Ich überlege gerade wie ich ein größeres Projekt aufbaue mit verschiedenen Themenbereichen.

Z.B Mitarbeiterverwaltung, Auftragswesen, Fahrzeugverwaltung etc...

Ich würde gerne alles in ein Programm packen habe aber die Befürchtung bzw. stehe vor der Frage wie verhalten sich nicht aufgerufene Elemente
(UserControls, Pages, Codebehind etc) zum Arbeitsspeicher. Werden Controls die es im Projekt gibt aber noch nicht zu sehen sind respektive noch nicht
mit "New" initialisiert wurden im Arbeitsspeicher bereit gestellt oder liegen sie einfach als Programmcode als "Datei" bereit und werden erst bei benutzen
wirklich im Arbeitspeicher hinterlegt? Da jeder von den oben genannten Punkten recht viele Controls haben wird stellt sich mir die Frage lieber mehrer
"Apps" daraus machen oder ist es im Grunde egal wie viele Controls (mit Codebehind) ein Projekt hat wenn man sie immer schön vernichtet wenn diese
nicht mehr gebraucht werden?

Vielen Dank im Vorfeld für eure Hilfe.

Größer is immer relativ. Was für dich groß sein kann, sind für andere mini.

Werden Controls die es im Projekt gibt aber noch nicht zu sehen sind respektive noch nicht
mit "New" initialisiert wurden im Arbeitsspeicher bereit gestellt oder liegen sie einfach als Programmcode als "Datei" bereit und werden erst bei benutzen
wirklich im Arbeitspeicher hinterlegt?

Das hat mit WPF nichts zutun, so funktioniert einfach .NET nicht. Objekte existieren im Speicher prinzipiell nur, wenn sie erzeugt werden - egal welche Art diese Objekte haben.

Wenn Du sauber programmierst, wie es in WPF vorgesehen ist ist - also mit Bindings, MVVM und Co - musst Du Dich um das Freigeben ungenutzter UI-Elemente prinzipiell nicht kümmern.
Was in Deiner Verantwortung liegt ist dass zB gebundene Listen nicht endlos gefüllt sind mit Inhalten, mit dem der Benutzer sowieso nichts anfangen kann (zB eine Tabelle mit 873642 Einträgen).

Der Gedankengang mit Single App vs. Multi App kann man machen, aber eigentlich nie aus Speicher-Management-Gründen.
Das fällt meiner Meinung klar unter premature optimization is the root of all evil.

Du wirst ein Speicherproblem dann haben, wenn Du falsch mit Objekten umgehst; aber nicht durch WPF selbst.

Vielen Dank für die ausführlich Info.

Wenn Du wirklich Bock hast das Speichermanagement von .NET zu verstehen, dann les Dir das Buch von Konrad Kokosa durch.
Pro .NET Memory Management: For Better Code, Performance, and Scalability

Aber wie gesagt, 99,999% der .NET Entwickler werden keine Speicher-Probleme bekommen, wenn sie die Regeln der jeweiligen Technologie einhalten.