I see much more gain in TinyVG in CPU usage to decode and render an image. XML is definitely not the most efficient way to expose data that is not meant for human consumption.
That would be what I’d care about the most. Smaller file size, but not an order of magnitude difference? Meh.
Easier for the browser to process? Well that’s going to have a tonne of useful ramifications.
Honestly that’s what annoys me about web services in general. (Rant mode enabled). The human readability aspect is moot because conversion is cheap, yet everything these days is built on XML, JSON and YAML.
The increasing use of middleman services whose entire job is to parse these formats into native types, then process the data, then serialise back into the same inefficient format, makes the issue a whole lot worse.
I mean, sure, this stuff is used so heavily that some amazing work has gone into parsing with SIMD at ridiculously high rates, but this is still orders of magnitude more time and effort for a CPU to perform the same thing with a native format. Even for things like strings, an actually-sensible representation like [length][body] would save all kinds of hassle by avoiding processing delimiters, searching for quotes, etc, and would make loading a value as simple as allocating the ALREADY KNOWN size and reading it.
Anyway, that’s my rant. The more parse-friendly formats out there the better.
XML, of course, is an opposite: It is a rather good way for humans to create data meant for computer consumption. Once the data are laid out, they can be transformed into a more efficient machine form in the same way a program is compiled, but for the web this is rarely done for any format, including pure machine-to-machine interaction. E.g. JSON is mostly used for machine-to-machine exchange and it is far from begin efficient for this.
Comments
I see much more gain in TinyVG in CPU usage to decode and render an image. XML is definitely not the most efficient way to expose data that is not meant for human consumption.
That would be what I’d care about the most. Smaller file size, but not an order of magnitude difference? Meh.
Easier for the browser to process? Well that’s going to have a tonne of useful ramifications.
Honestly that’s what annoys me about web services in general. (Rant mode enabled). The human readability aspect is moot because conversion is cheap, yet everything these days is built on XML, JSON and YAML.
The increasing use of middleman services whose entire job is to parse these formats into native types, then process the data, then serialise back into the same inefficient format, makes the issue a whole lot worse.
I mean, sure, this stuff is used so heavily that some amazing work has gone into parsing with SIMD at ridiculously high rates, but this is still orders of magnitude more time and effort for a CPU to perform the same thing with a native format. Even for things like strings, an actually-sensible representation like [length][body] would save all kinds of hassle by avoiding processing delimiters, searching for quotes, etc, and would make loading a value as simple as allocating the ALREADY KNOWN size and reading it.
Anyway, that’s my rant. The more parse-friendly formats out there the better.
XML, of course, is an opposite: It is a rather good way for humans to create data meant for computer consumption. Once the data are laid out, they can be transformed into a more efficient machine form in the same way a program is compiled, but for the web this is rarely done for any format, including pure machine-to-machine interaction. E.g. JSON is mostly used for machine-to-machine exchange and it is far from begin efficient for this.