On Thu, 7 Jan 2021, 12:52 Lorenzo Bertini, <lorenzobertin...@gmail.com> wrote:
> I think almost all the options are on the table at this point. For the > sake of completeness I think it's worth mentioning DOM library Boost > Property Tree, which popped up frequently while searching. > > I think Thibaut is right when saying that, for the way LyX is structured > now, a SAX writer would be more appropriate, because we won't work on > xml directly, but convert the LyX file. However most of the libraries > have a DOM approach, and also, if someday we'll convert LyX format to > something xml-like, we might have to start all of this again. > > I did a small benchmark with pugixml and to both read and write a xml > document of 2.2Mb of equivalent ~100/120 pages chock full of math: it > takes negligble time to both read and write on my really modest laptop > A10-9600). Peak memory consumption was 14Mb, but since some MathML was > corrupted (it has trouble with backslash \) it's possible it might be > way less once fixed: LyX consumption opening the corresponding LyX file > was ~120Mb. The benchmark table in > < > http://rapidxml.sourceforge.net/manual.html#namespacerapidxml_1performance> > > seems to indicate that pugixml and RapidXML have performance just one > order greater than strlen, so I don't think parse time will ever be a > problem. Thanks for your benchmark. For me, the major difference between the two libraries is that pugixml is still maintained, but not really RapidXML. And XML parsing is very often a source of security problems (not just XXE). I'm unfamiliar with the concept of "wrapping" libraries and "layers": is > it when you write your own classes and methods on top of some common > stuff those libraries do, so if for whatever reason you have to switch > you can "plug" another easily? > Yes, exactly. >
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel