Syntax für die Verwendung eines eigenen Comparers für String Vergleich.

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 28 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    ErfinderDesRades schrieb:

    das sollte in der Doku stehen


    Oh, Mann ... DEINE Routine gibt Werte größer +1 bzw. kleiner -1 zurück! Ich hab dir doch ein Beispiel dafür gepostet! Schau dir doch dein Coding mal genau an:

    VB.NET-Quellcode

    1. Return segments0.Length - segments1.Length


    MEINE Routine gibt nur -1, 0 und +1 zurück!

    :)

    was für die Sortierung doch egal ist.

    schau dir die Doku zur IComparer(Of T) - Schnittstelle an. Darauf kommt es an.

    Peter329 schrieb:

    So ein Comparer muss nicht zwingend -1, 0 oder +1 zurückliefern?
    Wie gesagt: Was ein Comparer muss, steht in der Doku.
    Wieso kriegt Rod ein Hilfreich für seine persönliche Vorliebe, und ich nicht, wenn ich dir sag, dass inne Doku nachzulesen ist, wie's muss?


    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Peter329 schrieb:

    VB.NET-Quellcode

    1. segments0.Length - segments1.Length
    sortiert einfach der Länge nach. :D
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Ihr kriegt jetzt beide kein "hilfreich" mehr, weil ihr am Thema vorbei diskutiert! hehehehe :D

    Also, was soll das denn werden? Mir geht hier doch gar nicht um das Sortierverfahren ... das funtioniert prima .... und das habe ich auf Herz und Nieren getested.

    Und mein Abgleich der Registry funktioniert auch wunderbar ... Ich erhalte in ein paar Sekunden einen Report über alle Änderungen der Registry gegenüber einem früheren Zeitpunkt. Das war es woran ich einige Tage gearbeitet habe. :)

    Worum es in diesem Thread jetzt noch ging, war die Frage zum Sortierer ... warum der "Singleton" wider Erwarten ein bissl länger nudelt als erwartet. Na ... aber damit kann ich auch leben.

    Also, erst mal recht herzlichen Dank für euer Engagement und eure Hilfsbereitschaft. Ihr habt mir sehr geholfen. Und natürlich kriegen jetzt alle auch noch einen Haken ... hehehe ... :D

    LG
    Peter

    Das sind vmtl. Messungenauigkeiten.
    wenn ich zuerst das mit New messe, und danach die Instance, dann ist die Instance schneller.
    Ich glaub da wird ein String-Cache angelegt.

    und nochmal: der Standard-StringComparer mit IgnoreCaseOrdinal ist identisch zu deiner Sortierung mit .ToUpper + <, nur ist gut stück schneller.

    Die Sache mit dem Cache könnte die Sache mit den Laufzeiten erklären. Das schau ich mir noch mal an.

    ErfinderDesRades schrieb:

    und nochmal: der Standard-StringComparer mit IgnoreCaseOrdinal ist identisch zu deiner Sortierung mit .ToUpper + <, nur ist gut stück schneller.


    Ok, jetzt hab ich das geschnallt! Also auch das schau ich mir jetzt noch mal na!

    LG
    Peter

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „Peter329“ ()

    So, da bin ich wieder. Ich hab das jetzt mit dem "OrdinalIgnoreCase" Comparer realisiert.

    Der Aufbau der Extrakt Files erfolgt mit dem Array.Sort

    VB.NET-Quellcode

    1. Array.Sort(SubkeyList, System.StringComparer.OrdinalIgnoreCase)


    Und der Abgleich verwendet dann zum Vergleich der Keys:

    VB.NET-Quellcode

    1. Dim segments0() As String = strKey(0).Split("\"c) '"'old key
    2. Dim segments1() As String = strKey(1).Split("\"c) '"'new key
    3. For i As Integer = 0 To Math.Min(segments0.Length, segments1.Length) - 1
    4. Dim val = StringComparer.OrdinalIgnoreCase.Compare(segments0(i), segments1(i))
    5. If val <> 0 Then Return val
    6. Next
    7. Return segments1.Length - segments0.Length


    Damit ist sichergestellt, dass Extrakt und Abgleich exakt die gleiche Sortierreihenfolge verwenden. Denn wie schon gesagt, das ist für einen Match-Merge entscheidend. Zum anderen ist der Aufwand für den Code gesunken. Das hat ja auch etwas für sich.

    Allerdings ... performancemäßig tut sich leider nix ... es bleibt bei 5 sec Laufzeit für den Abgleich von je 850.000 Sätzen. Na ... dann will ich mal damit zufrieden sein. So bleibt die Kiste jetzt!

    LG
    Peter

    oh, da geht noch einiges!
    Die Registry-Daten sind ja eine Baum-struktur, und entsprechend kannst du sie auch in eine Baumstruktur einlesen.
    Dabei gleich die Zweige sortieren - das sind ja meist nicht mehr als vlt. 10 Blätter. Auf diese Weise wäre Registry einlesen und Sortieren eins - müsste sehr flott gehen.
    Wieviel Zeit beansprucht bei dir das Registry einlesen selbst?

    Ein annerer Vorteil einer Baumstruktur wäre, man muss nicht von jedem Blatt den ganzen Pfad merken, sondern nur den Namen.
    Das spart beim Abspeichern Platz.