TJSONToObject Performance

[fisipjm]

Hi,

Ich habe ein kleines Problem mit der Performance von TJSONtoObject. JSON ist grob so aufgebaut.

Code:

{
    "objects": [
        {
            "value1": "value",
            "value2": "value",
            "value3": "value",
            "value4": "value",
            "value5": "value",
            "value6": "value",
            "value7": "value",
            "value8": "value",
            "value9": "value"
        },
        {
            "value1": "value",
            "value2": "value",
            "value3": "value",
            "value4": "value",
            "value5": "value",
            "value6": "value",
            "value7": "value",
            "value8": "value",
            "value9": "value"
        }
    ]
}

Ich bekomme eine Server Response. Im Array sind ca. 65.000 Objekte. Nutze ich JSONToObject um das JSON in eine Klasse zu pumpen und dann darauf zuzugreifen, dauert das ca. 15,7 Sekunden.
Wenn ich über das JSONObject selbst außeinander nehme, dauert es 2,8 Sekunden.
Auf dem PC, auf dem mobilen Endgerät ist dann beides nochmal um den Faktor 4 langsamer (Wahrscheinlich geräteabhängig). Nur mit 10 Sekunden kann man halt leben, mit 1 Minute wirds dann schon langsam nervig.

Ich würde ungern das JSON händisch durchgehen, habt ihr eine Idee oder einen Tipp wie man noch ein bisschen Performance aus dem JSONToObject rausholen könnte?

LG
PJM

[Olli73]

Wie sieht denn deine Klasse aus?

Und irgendwie müsstest du die Länge / Kapazität des Arrays vorher passend setzen, damit es nicht ständig vergrößert werden muss.

[fisipjm]

Moin Olli,

die Klasse sieht so aus:

Delphi-Quellcode:

type
TArrayClass<T: Class> = class
    private
        fObjects: TArray<T>;
    public
        property Objects: TArray<T> read fObjects write fObjects;
    end;


 TBaseClass = class
    private
        fValue1: string;
        fValue2: string;
        fValue3: string;
        fValue4: string;
        fValue5: string;
    public
        property Value1: string read fValue1 write fValue1;
        property Value2: string read fValue2 write fValue2;
        property Value3: string read fValue3 write fValue3;
        property Value4: string read fValue4 write fValue4;
        property Value5: string read fValue5 write fValue5;
    end;

TExtenderClass = class(TBaseClass)
    private
        fValue6: string;
        fValue7: string;
        fValue8: string;
        fValue9: string;
    public
        property Value6: string read fValue6 write fValue6;
        property Value7: string read fValue7 write fValue7;
        property Value8: string read fValue8 write fValue8;
        property Value9: string read fValue9 write fValue9;
    end;

TCompleteList = class(TArrayClass<TExtenderClass>);

....
var
  lList: TCompleteList;
...

  lList:= TJson.JsonToObject<TCompleteList>(MyJSONString);
...

[fisipjm]

Zitat:

Zitat von Olli73 (Beitrag 1533363)

Und irgendwie müsstest du die Länge / Kapazität des Arrays vorher passend setzen, damit es nicht ständig vergrößert werden muss.

Hab ich versucht, ändert aber nichts. Im Gegenteil, der Prozess die Gesamtlänge herauszufinden und das Array entsprechend zu setzen bringt mir eine weitere Sekunde Wartezeit ein.

[Olli73]

Ich kenn das nur so:

Delphi-Quellcode:

TCompleteList = class
    FObjects: TArray<TExtenderClass>;
  end;

Macht DAS einen Unterschied?

[fisipjm]

Zitat:

Zitat von Olli73 (Beitrag 1533389)

Ich kenn das nur so:

Delphi-Quellcode:

TCompleteList = class
    FObjects: TArray<TExtenderClass>;
  end;

Macht DAS einen Unterschied?

Nein, kein Unterschied.

[Uwe Raabe]

Bei Performanceproblemen gibt es viele mögliche Ursachen. Könntest du einen konkreten Testfall mit dem entsprechenden JSON erstellen mit dem wir das nachstellen können?

[fisipjm]

Zitat:

Zitat von Uwe Raabe (Beitrag 1533396)

Bei Performanceproblemen gibt es viele mögliche Ursachen. Könntest du einen konkreten Testfall mit dem entsprechenden JSON erstellen mit dem wir das nachstellen können?

Kurz was zusammengewürfelt.
Hier wird der Unterschied sogar noch viel deutlicher.

[Uwe Raabe]

Es ist wohl richtig, dass eine direkte Verarbeitung des JSONObject schneller ist als das RTTI-basierte JsonToObject. Selbst bei der Umwandlung der einzelnen Values weißt du ja schon, dass es sich um Strings handelt und kannst das durch den gezielten Aufruf von TryGetValue<string> ausnutzen, während andernfalls immer der Umweg über TValue erfolgen muss.

Also, ja, direkt das JSON abzuarbeiten ist deutlich performanter - aber eben auch aufwändiger und schlechter wartbar. Du musst halt abwägen.

[fisipjm]

Zitat:

Zitat von Uwe Raabe (Beitrag 1533413)

Also, ja, direkt das JSON abzuarbeiten ist deutlich performanter - aber eben auch aufwändiger und schlechter wartbar. Du musst halt abwägen.

Das hab ich befürchtet :? Danke aber trotzdem für die Rückmeldung :thumb:

[mytbo]

Zitat:

Zitat von fisipjm (Beitrag 1533407)

Kurz was zusammengewürfelt.
Hier wird der Unterschied sogar noch viel deutlicher.

Die Werte für mORMot für den Test im Anhang liegen zwischen 150 und 300 Millisekunden. Du kannst auch deine Testdatei speichern und in den JsonViewer aus diesem Artikel laden. Die Ladezeit wird links unten eingeblendet.

Bis bald...
Thomas

[fisipjm]

Zitat:

Zitat von mytbo (Beitrag 1533418)

Zitat:

Zitat von fisipjm (Beitrag 1533407)

Kurz was zusammengewürfelt.
Hier wird der Unterschied sogar noch viel deutlicher.

Die Werte für mORMot für den Test im Anhang liegen zwischen 150 und 300 Millisekunden. Du kannst auch deine Testdatei speichern und in den JsonViewer aus diesem Artikel laden. Die Ladezeit wird links unten eingeblendet.

Bis bald...
Thomas

Das Sieht sehr vielversprechend aus :)
Gibt es einen Grund warum du den "Umweg" über ein File nimmst und nicht direkt mit einem String arbeitest?
Ich habe es mal eben versucht mit einem normalen String umzusetzen, aber bekomme es nicht hin, kenne das Framework dafür zu wenig :oops:

Edit: Ne passt, hab mich bissel eingelesen und gesehen, dass die Felder, die in der Klasse verwendet werden sollen in Published liegen müssen. Macht RTTI seitig natürlich Sinn. Danke für das Beispiel ��

[fisipjm]

Zitat:

Zitat von fisipjm (Beitrag 1533430)

Zitat:

Zitat von mytbo (Beitrag 1533418)

Zitat:

Zitat von fisipjm (Beitrag 1533407)

Kurz was zusammengewürfelt.
Hier wird der Unterschied sogar noch viel deutlicher.

Die Werte für mORMot für den Test im Anhang liegen zwischen 150 und 300 Millisekunden. Du kannst auch...

Das Sieht sehr vielversprechend aus :)

Ich hab gerade gesehen das mORMot2 nicht unter Android läuft :( ich brauch das ganze leider für mobile Development also iOS und Android :pale:

[mytbo]

Zitat:

Zitat von fisipjm (Beitrag 1533437)

Ich hab gerade gesehen das mORMot2 nicht unter Android läuft :( ich brauch das ganze leider für mobile Development also iOS und Android :pale:

Gibt es für mORMot1. Die Namen der Funktionen könnten sich geändert haben. Das Fork Repository findest du auf GitHub. Habe es selbst nicht getestet. Und jetzt blamiere ich mich, sollte der Autor hier zufällig mitlesen, sein Name ist Thomas K...? Die restlichen Buchstaben sind in den unendlichen Weiten verschwunden.

Bis bald...
Thomas

[fisipjm]

Zitat:

Zitat von mytbo (Beitrag 1533443)

Zitat:

Zitat von fisipjm (Beitrag 1533437)

Ich hab gerade gesehen das mORMot2 nicht unter Android läuft :( ich brauch das ganze leider für mobile Development also iOS und Android :pale:

Gibt es für mORMot1. Die Namen der Funktionen könnten sich geändert haben. Das Fork Repository findest du auf GitHub. Habe es selbst nicht getestet. Und jetzt blamiere ich mich, sollte der Autor hier zufällig mitlesen, sein Name ist Thomas K...? Die restlichen Buchstaben sind in den unendlichen Weiten verschwunden.

Bis bald...
Thomas

Hi Thomas,

vielen Dank für deine Antwort mOrMot1 wird nicht mehr weiter entwickelt, wenn ich das richtig verstanden habe. Ich hab ein wenig Bauchschmerzen ein so großes Framework in das Projekt zu integrieren, wenn bereits jetzt klar ist, das es nur noch maximal Fixes geben wird.
Ich habe aber gesehen, dass es im Projekt eine einzige Unit gibt, die für sich genommen lauffähig ist.
SyncCrossPlatformJSON.pas - Hab diese Mal in das Projekt integriert, aber es sieht so aus, als würde dort das JSONToObject nicht mit dem Array arbeiten können. Zumindest ist meine Klasse immer leer (Ohne Fehler). Hast du damit zufällig Erfahrung?

LG
PJM

[mytbo]

Zitat:

Zitat von fisipjm (Beitrag 1533448)

Ich habe aber gesehen, dass es im Projekt eine einzige Unit gibt, die für sich genommen lauffähig ist.
SyncCrossPlatformJSON.pas - Hab diese Mal in das Projekt integriert, aber es sieht so aus, als würde dort das JSONToObject nicht mit dem Array arbeiten können. Zumindest ist meine Klasse immer leer (Ohne Fehler). Hast du damit zufällig Erfahrung?

Richtig, mORMot1 wird nicht weiter entwickelt, aber noch gepflegt. Units aus mORMot1 werden auch in anderen bekannten Frameworks verwendet. Ich persönlich hätte an dieser Stelle keine Bedenken. Am besten stellst du diese Frage im mORMot Forum. Allerdings würde ich die CrossPlatform Units nicht verwenden. Die wurden so geschrieben, dass sie auch mit einem Transpiler nach JavaScript übersetzt werden konnten. Damals noch für das Produkt SMS.

Bis bald...
Thomas

[QuickAndDirty]

ehm
Es gibt einen Delphi to JS oder WASM transpiler ?

[mytbo]

Zitat:

Zitat von QuickAndDirty (Beitrag 1533482)

Es gibt einen Delphi to JS oder WASM transpiler ?

Die ich kenne: Pascal to JavaScript, TMS WEB Core, SMS (Smart Mobile Studio), QTX (Quartex Pascal). Die Reihenfolge der Aufzählung stellt keine Präferenz dar.

Bis bald...
Thomas