4 ms·

XML get's used in a lot of places it shouldn't be used. It also has two competing standards for parsing one of which is far too heavyweight for many of the use

by zaphar 4y ago

XML get's used in a lot of places it shouldn't be used. It also has two competing standards for parsing one of which is far too heavyweight for many of the use cases it has been used in. 9 times out of 10 for data transport you want SAX parsing not DOM. Unless your XML is actually a marked up document DOM is overkill. But many data transport libs used to use DOM which has a very real performance cost. I'm not sure how much of that is still true but the reputation for bloat and being heavy weight was often caused by parsing to DOM and then deserializing from there.

tablespoon 4y ago
> XML get's used in a lot of places it shouldn't be used. It also has two competing standards for parsing one of which is far too heavyweight for many of the use cases it has been used in. That's not the standard's fault. DOM and SAX (or rather streaming parsing in general) both have their places, it's up to the developer to know when to use which. Of course, developers often make bad choices, but the only way a standard can "solve" that is by forcing a developer to make bad choices in some contexts, so it's not the developer's fault anymore.
- zaphar 4y ago
  It's not the standards fault per se but that doesn't change the fact that the standard now has a reputation whether it wanted it or not.
planede 4y ago
I have some experience with libxml2. I would say DOM parsing is partly inefficient due to the many small allocations, and the library does not offer fine grained control over it. The allocator is globally replaceable, but that's not very flexible. I wished many times if I could just use an arena with a dumb allocator for a small document and just drop it when I finish with the document, but it's not very easy to do with libxml2, unless you write your own DOM parser on top of SAX.
- sgerenser 4y ago
  I’ve made good use of PugiXML: https://pugixml.org/ https://pugixml.org/. Faster than most SAX parsers with the simpler interface of DOM. Gets around the small allocation problem by making a mutable copy of the entire input, then modifying it in place, and only allocating (using arenas) when absolutely necessary. C++ though so not very easy to use from other languages like libxml2 is.
  - planede 4y ago
    It looks interesting, but it looks like it has no or limited XML namespace support, which is a shame.
- zaphar 4y ago
  Probably true but also DOM parsing is usually not necessary and streaming parsing is not that hard so why not just skip the DOM and go straight to streaming instead?
  - planede 4y ago
    DOM parsing is not necessary until it is. Sometimes you can get away with parsing the stream twice and still beat DOM parsing, but not always. Stream parsing is indeed preferable when you can get away with it.
ben7799 4y ago
Lots and lots of applications make the exact same mistakes with Json. Read the entire document into memory and let Jackson parse it out into a heavyweight object graph. Blech.
- zaphar 4y ago
  Well, yes. But the difference between a JSOn object graph and an XML Document Object Model is night and day in terms of size. Not even close to comparable.

by zaphar 4y ago

tablespoon 4y ago

> XML get's used in a lot of places it shouldn't be used. It also has two competing standards for parsing one of which is far too heavyweight for many of the use cases it has been used in. That's not the standard's fault. DOM and SAX (or rather streaming parsing in general) both have their places, it's up to the developer to know when to use which. Of course, developers often make bad choices, but the only way a standard can "solve" that is by forcing a developer to make bad choices in some contexts, so it's not the developer's fault anymore.

zaphar 4y ago
It's not the standards fault per se but that doesn't change the fact that the standard now has a reputation whether it wanted it or not.

planede 4y ago

I have some experience with libxml2. I would say DOM parsing is partly inefficient due to the many small allocations, and the library does not offer fine grained control over it. The allocator is globally replaceable, but that's not very flexible. I wished many times if I could just use an arena with a dumb allocator for a small document and just drop it when I finish with the document, but it's not very easy to do with libxml2, unless you write your own DOM parser on top of SAX.

sgerenser 4y ago
I’ve made good use of PugiXML: https://pugixml.org/ https://pugixml.org/. Faster than most SAX parsers with the simpler interface of DOM. Gets around the small allocation problem by making a mutable copy of the entire input, then modifying it in place, and only allocating (using arenas) when absolutely necessary. C++ though so not very easy to use from other languages like libxml2 is.
- planede 4y ago
  It looks interesting, but it looks like it has no or limited XML namespace support, which is a shame.
zaphar 4y ago
Probably true but also DOM parsing is usually not necessary and streaming parsing is not that hard so why not just skip the DOM and go straight to streaming instead?
- planede 4y ago
  DOM parsing is not necessary until it is. Sometimes you can get away with parsing the stream twice and still beat DOM parsing, but not always. Stream parsing is indeed preferable when you can get away with it.

ben7799 4y ago

Lots and lots of applications make the exact same mistakes with Json. Read the entire document into memory and let Jackson parse it out into a heavyweight object graph. Blech.

zaphar 4y ago
Well, yes. But the difference between a JSOn object graph and an XML Document Object Model is night and day in terms of size. Not even close to comparable.