Rolf B: Konzept: PHP-include oder mySQL stored procedures?

Beitrag lesen

Hallo Linuchs,

Ich mag Zwetsch(g)enkuchen, du empfie(h)lst Sahnetorte.

Ich mag vor allem Zwetschgenkuchen mit Sahne drauf!

Ja, JSON ist geschwätziger, weil es Objekte als Key-Value Paare speichert. Bei einer einzigen Datenzeile ist das genau wurscht.

Bei 1000 Datenzeilen und geschätzten 400 Bytes für Propertynamen sind das 400K Mehrdatenvolumen; vermutlich mehr Daten für Overhead als für Inhalt, also schon sehr signifikant. Das kannst Du durch GZIP Kompression der dynamisch erzeugten Inhalte kompensieren (beim IIS muss ich das explizit einschalten); da die Propertynamen ständig gleich sind, komprimieren sie gut. Dafür dauert das GZIPpen seine Zeit und mümmelt CPU Kerne.

Deine Abwägung, und Du hast sie getroffen.

Ich hätte eine Challenge für Dich. Du könntest das Datenvolumen noch mehr straffen, wenn Du ein binäres Format statt CSV wählst.

  1. bestimme die String-Repräsentation jedes Feldes
  2. setze vor den Feldinhalt ein Zeichen, dessen Zeichencode der Feldlänge entspricht. Bei UTF-8 Codierung gehen Feldlängen bis 127 als ein Byte über die Leitung.
  3. setze Feldlängen und Feldinhalte zusammen und setze davor noch ein Zeichen, dessen Zeichencode der Anzahl der Felder entspricht.

So schreibst Du Satz für Satz 'raus. Auf String-Delimiter und Escaping von Sonderzeichen brauchst du nicht zu achten, wegen der Feldlängenangaben. Nach dem letzten Satz schreibst Du noch ein Nullbyte - ein Satz ohne Felder - als Terminator.

Rolf

--
sumpsi - posui - obstruxi