In upcoming GXml 0.14, there will be a new DOM4 implementation called GomDocument, it along with GomElement and GomObject, provides support to serialize or deserialize GObject object to or from XML files.
I’ve made initial measures about what is the performance of GomDocument against other implementations in GXml: GDocument and TDocument, first one is a libxml2 implementation with bidings on GObject and DOM4 while last one is a pure GObject implementation with no support (yet?) of DOM4.
In performance test, we use a 3.5 MB file with a lot of nodes, read it and then create an internal in memory XML tree and then fill out your GObject class properties, we measure required time to deserialize and then time to write it back to an XML file.
We can see GDocument taking a lot of time on deserialize, because it uses libxml2 to create a tree and GXml.SerializableObjectModel to fill out your GObject class. Serialize is very competitive, because all implementations, use almost same engine: direct access to libxml2 by xmlWriter.
GomDocument, is very competitive if compared to TDocument, but can perform much better than GDocument.
Please note that GomDocument time to write to disk is not available, because serialization and deserialization is make in one go, then may be we case reduce this time (should be the same from others because the file is loaded in memory before to read) and then this makes GomDocument to perform even better!!
On memory usage, TDocument requires much more memory and GDocument is the one to defeat. GomDocument now requires almost same memory than GDocument.
Conclusion
GomDocument is the way to go on Serialization framework for GXml. These results will help LibreSCL, to provide a very competitive serialization/deserialization framework and consider to create a WEB based application using GObject Introspection and Python to access very large files, without requiring lot of memory resources and may be a good response time on reading.
I’m starting to stabilize GXml to release 0.14 as soon as I can found most bugs on parse XML files. GXml’s GomDocument have a set of errors detection, based on DOM4, not present in other GXml implementations, making it more sensitive to some files and may not affecting (or detected) by libxml2, for example.
There’s already a GNOME library using the “gom” namespace. Would be great if it wasn’t trampled on.
No namespace problem here. When used together, you should use GXml.GomElement, for example.
Hi Daniel,
Don’t all these `Gom*` names conflict with the ones from gom?
https://git.gnome.org/browse/gom/
All Gom objects are under GXml namespace, then no conflict here. In future releases, I would like to reduce number of implementations in order to reduce nested namespaces.