Suchergebnisse

Hallo, nachdem ich ja in letzter Zeit nicht mehr online war, hab ich mal wieder eine kleine Frage: Und zwar hab ich ziemlich viele Datensätze, und es mag User meines Programms geben, die sogar noch mehr haben. Es geht um einige tausend. Diese muss ich in irgendeiner Weise beim Beenden des Programms abspeichern, was ich bisher mit JSON getan habe. Das Serialisieren der Daten ist aber viiiell zu langsam, ich rede hier von, ich habs nicht gemessen, aber das sind gut und gerne 30 Sekunden, wenn nich…

Zitat von VaporiZed: „Da stimmt wirklich was nicht.“ Echt? Da bin ich erstmal froh, dass das wahrscheinlich nen anderen Grund hat... Zitat von VB1963: „Wohin werden diese Daten gespeichert auf PC-Platte, irgendwo über ein Netzwerk oder gar über I-Net?“ Die Daten werden auf SSD gespeichert, aber das scheint nicht das Problem zu sein. Habs grad nochmal mit nem Haltepunkt versucht, es ist definitiv das Serialisieren selbst, nicht das Speichern: VB.NET-Quellcode (2 Zeilen) Habs nochmal grad mit nem …

@RodFromGermany Dat is doch mal ne Ansage Wie gesagt, das Speichern läuft wie am Schnürchen, das Deserialisieren Auch. Nur das Serialisieren dauert so lang... Also ich werd einfach mal die Datei mit dem Originaldatensatz nehmen die dann deserialisieren und wieder serialisieren und das Ganze stoppen. Bis später

Hier das Benchmarkprogramm. Ich hoffe, ich hab nicht zu viele Dateien/Ordner aus dem ZIP gelöscht. Den Ordner mit dem JSON Nugetpaket hab ich komplett rausgenommen. Die dtb-Datei müsst ihr in den bin/Debug-Ordner kopieren. Merkwürdigerweise, mit der selben Datei wie in meinem Hauptprojekt, alles unter 1 Sekunde...auch bei mir Der einzige Unterschied: In der Datei MP3FileInfoVM ganz unten hab ich die Klasse ColorInfo und alle Verweise darauf auskommentiert, weil die natürlich in einem Konsolenpr…

@ErfinderDesRades Jou isses ja auch nicht. Aber diese Werte bekomm ich nur mit diesem Testprogramm. In meinem grossen Projekt mach ich es genauso, und da hab ich halt mal kurz 13 Sekunden...

Zitat von ErfinderDesRades: „Verwende Streams und Reader, dann werden Dateien stückweise gelesen und verarbeitet, und belegen keine so Riesen-Blöcke.“ Alles klar, man lernt nie aus Zitat von ErfinderDesRades: „(Ansonsten bin ich recht verzweifelt über deinen unleserlichen Codier-Stil, aber dem willst du wohl nicht abhelfen)“ Ah sry, normalerweise wenn ich ein Testprogramm mache oder nen komplizierteren Code poste, nehm ich dann mal auch dementsprechende Variablennamen... Hatte ich jetzt glatt ve…

@RodFromGermany Okay ja das ist deutlich zu sehen. Ich hab das "schwerwiegende" Problem aber beim Serialisieren, nicht beim Deserialisieren. Vielleicht ein WPF-Problem? Oder mal probieren explizit vom MainThread aufzurufen? Ich kann echt nur raten. Achja genau, vielleicht tuts was zur Sache: Aufgrund der langen Wartezeit beim Serialisieren hatte ich vor einiger Zeit auch versucht, vor dem Serialisieren eine selbst gebaute MessageBox anzuzeigen, die den Nutzer auf dieses Manko hinweist. Die wurde…

Zitat von Haudruferzappeltnoch: „trennt man das Binding während des Ladevorgangs kurzzeitig, ist alles fein.“ Das bestätigt meine Ahnung Aber kannst du mir auch sagen wie das geht? Ist nämlich eine MVVM-Application und ich hab nur das hier gefunden, das mag bei Code Behind richtig sein, aber wüsste nicht wie ich das vom ViewModel aus machen soll...: learn.microsoft.com/en-us/dotn…w=netframeworkdesktop-4.8 @ErfinderDesRades Ich vergess dich nicht, ich geh jetz bloss erstmal der Spur von @Haudrufe…

@ErfinderDesRades Nochmal ums klarzustellen: -Deserialisieren -> kein Problem -Serialisieren -> Big Problem Also hab ich jetzt mal noch ein zweites Testprojekt gemacht. Diesmal in MVVM und siehe da, ich komm wieder auf meine 13 Sekunden, und zwar egal ob das Binding mit dem DataGrid besteht oder nicht... Das macht das Ganze jetzt ja auch nicht weniger komisch, oder? Probierts aus, ich bin mit meinem Latein da echt am Ende...: Code habt ihr dann ja

Echt jetzt? Da wär ich nie drauf gekommen, das hat mir damals Nofear23m so beigebracht das so zu machen. Hab ich bis heut nicht ganz geschnallt warum er das jetzt so macht... Muss ich gleich morgen mal umschreiben. Liegt wahrscheinlich daran, dass die Projektmappe so strukturiert ist dass sie jeweils für Model, View und ViewModel inne extra dll kompiliert. Musst mal im Ausgabeordner gucken da siehst dus...

@ErfinderDesRades Kommando zurück, die Lösung ist das anscheinend noch nicht... Denn: Das geht zwar schneller, aber man bekommt am Ende 5486 Datensätze gefüllt mit Nullen abgespeichert... Ich verstehe nicht warum, denn in der MP3FileInfoVM wird das doch befüllt...: VB.NET-Quellcode (2 Zeilen) Also entweder wir finden raus, warum ModelObjekt voll mit Nullen ist und probierens dann nochmal oder ich muss tatsächlich umsteigen auf SQLite oder sowas in der Art. Was ich schon probiert hab ist diesesMP…

@dive26 Okay das ist schon mal 3-4 Sekunden schneller ohne dass ich den String der Variable zuweise. Immerhin etwas. Ich probier jetzt auch noch die Tipps aus Post 7 von @VB1963 aus. Man bemerke: Das Komische an sich ist, dass ich mit der Konsolenanwendung (Post 8) unter 1 Sekunde liege, in der WPF MVVM-Version (Post 20) aber bei 13 Sekunden... Edit: @VB1963 Ich brauch da bisschen Hilfe mit dem JSONTextWriter. Hier findet man die Docs, die machen mich aber auch nicht schlauer. Ich glaube das Pro…

@mrMo Auf was beziehst du dich jetzt? Auf die Verschachtelung? Ich mach das ja manuell aus dem Grund weil das ja laut Link in Post 7 schneller sein soll, was ja der Grund für das Ganze Schlamassel ist... Edit: Hiermit gehts unter 1 Sekunde, die verschachtelten Werte hab ich aber aussen vor gelassen... Hat jemand ne Idee wie ich das implementiren kann? In den Docs hab ich nur was von .WriteStartArray() gefunden, ich hab ja aber OCs...: (Versteckter Text) Habs hinbekommen Man kommt damit jetzt unt…

Ich glaub ich weiss warum das bei der Konsolenanwendung so schnell ging und bei der MVVM-Version nicht. Zum Einen, ja, wenn man das manuell serialisiert geht's wahrscheinlich bisschen schneller - lässt sich jetzt aber schlecht testen. Zum Anderen hat das manuelle Serialisieren ja glaub ich den Vorteil, dass du aussuchen kannst welche Properties mit einbezogen werden. Muss ich aber noch genau testen. Jetzt hat dieses MP3FileInfoVM noch aber zwei vererbte Properties: "IsInDesignMode" und "VMIsBusy…

So, jetzt kommt gleich das nächste Folgeproblem Ich habe in CueMarkers zwei Eigenschaften Farbe As Windows.Media.Color und SampleBrush As Windows.Media.SolidColorBrush. Diese Typen unterstützt der JsonTextWriter aber nicht. Also hab ich beim Serialisieren ein .ToString angehängt: VB.NET-Quellcode (5 Zeilen) Funktioniert. Bloss wenn ich dann deserialisiere: VB.NET-Quellcode (4 Zeilen) Kommt ein Fehler wegen falschen Datentyp. Weiss jemand vielleicht wie ich das umgehen kann? Etwa auch manuell des…

Zitat von VaporiZed: „Kannst Du nicht diese Typen vor Serialisierung in serialisierbare Typen umwandeln? Irgendwelche Integer-Pakete oder System.Drawing.Colors oder so? Und nach Desierialisierung wieder zurück? Sodass Du quasi Properties für die App hast und Properties für die Serialisierung?“ Ja genau da versuch ich ja. Aber hab schon eine bessere Lösung gefunden: Hab das Ganze manuelle Serialisieren wieder über den Haufen geworfen und die Properties, die ich nicht mit serialisiert haben möchte…