Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support using libxml SAX mode as the XML parser #3

Open
mithro opened this issue Jul 2, 2019 · 6 comments
Open

Support using libxml SAX mode as the XML parser #3

mithro opened this issue Jul 2, 2019 · 6 comments

Comments

@mithro
Copy link
Member

mithro commented Jul 2, 2019

As you showed previously, using a SAX parser has significant advantages in memory usage. Now that we are auto-generating the parser, it would be good to have the option between pugixml (for the highest speed) and a SAX parser for the lowest memory usage.

@duck2
Copy link
Member

duck2 commented Jul 2, 2019

Using XPath with a SAX parser is not possible(or at least it kills its purpose because you build an in-memory representation), so this wouldn't work with anything under the constraint components of XSD.

But it could be used to verify types, model groups, attributes, etc.

@mithro
Copy link
Member Author

mithro commented Jul 2, 2019

You should be possible to generate a post-structure creation checker?

@duck2
Copy link
Member

duck2 commented Jul 2, 2019

Makes sense! If xml files can map to structs, maybe xpaths can somehow map to struct accesses.

@mithro
Copy link
Member Author

mithro commented Jul 2, 2019

I think that kind of makes sense...

@litghost
Copy link
Contributor

I've done a quick test, and it looks like the pugixml parser isn't that much faster than libxml2's SAX mode, and the SAX mode uses significantly less memory. Given the new interface based approached, could we implement a SAX mode?

@duck2
Copy link
Member

duck2 commented Nov 27, 2019

That makes more sense since the interface is looking more like SAX.

Pugi is quite faster than libxml2 SAX, though. I have tested it a lot when doing vtr-verilog-to-routing/pull/34, and however hard I tried to optimize the SAX-based parser(perfect hashes, indexed function lookups and all), it fell short of the unoptimized Pugi-based one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants