2016-07-09 6 views
2

Ich baue eine Webgl-Anwendung. Und es erfordert Deserialisierung von Daten ~ 15MB (das ist die Größe eines einzelnen Objekts, ich werde etwa 10 davon in meiner Anwendung haben) und der größere Teil (90%) dieser Daten ist ein paar Arrays von Fließkommazahlen und diese Arrays müssen in Float32Arrays in JavaScript deserialisiert werden.Besser performante Alternativen von JSON auf mobilen Geräten

Derzeit verwende ich JSON. Da meine Daten viele Wiederholungszahlen enthalten, ist sie stark komprimierbar und ich bin mit der Netzwerkleistung zufrieden. Außerdem. Ich bin auch mit der Leistung auf dem Desktop zufrieden. Das Laden, Deserialisieren der Daten in reine JS-Arrays und das anschließende Konvertieren in Float32Arrays auf mobilen Geräten erfordert jedoch viel Zeit.

ich als protobuff verwenden, aber ich sah dieses auf https://protobuffers.codeplex.com/

Protocol Buffers sind keine großen Nachrichten zu verarbeiten entworfen. Wenn Sie Nachrichten verarbeiten, die größer als ein Megabyte sind, ist es möglicherweise Zeit eine alternative Strategie zu betrachten.

Was kann ich tun, um die Leistung meiner Anwendung zu verbessern? Welche SERDES-Methoden sollte ich testen?

Bitte führen Sie mich durch diesen Prozess und helfen Sie mir, meine Alternativen zu testen, werde ich mehr Details stellen, wenn Sie etwas in den Kommentaren fragen.

+1

Haben Sie sich BSON angesehen? – Bergi

+0

@Bergi Ich überprüfe das jetzt! – Hasan

+0

Ist die 15MB die Größe der serialisierten JSON-Daten oder die Größe der Daten im Speicher nach der Deserialisierung? Laut http://bsonspec.org/spec.html sieht es so aus, als ob BSON 64-Bit-Floats speichert, nicht 32bit, was sehr schade ist. Protocol Buffers haben einen Double und einen Float, also für Ihre 32bit Float Arrays, die kompakter als BSON sind und eine gute Chance haben schneller zu sein. – bazza

Antwort

1

Wenn Ihr Objekt wie ein großes Array von Gleitkommazahlen ist, können Sie die rohen Bytes anstelle einer JSON-codierten Zeichenfolge senden.

XMLHttpRequest hat responseType = "arraybuffer". Damit wird Ihr "Parsing-Schritt" auf var floats = new Float32Array(xhr.response) reduziert.

Und es würde sogar die Auswirkungen dieser Aufgabe auf den Speicher reduzieren, weil Sie nicht brauchen eine 15MB große String + eine Zwischen-Array mit vielleicht etwa 20MB Double, ich denke, + die resultierende Float32Array mit weiteren 10MB (die Hälfte der Doppel) alles ungefähr zur gleichen Zeit.

Sie haben 1 ArrayBuffer, der nur die rohen Bytes enthält + ein Float32Array, das auf diese Daten im Speicher verweist.


Wenn dies für Sie nicht funktioniert, könnten Sie vielleicht die Art/Struktur der Daten erklären, die Sie senden.

Oder vielleicht der Code, den Sie im Backend verwenden, wenn die Serialisierung das Problem ist.