-
Notifications
You must be signed in to change notification settings - Fork 46
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
Parsing can be 20x slower w/ pygccxml vs. in-memory solutions? (e.g. clang.cindex) #129
Comments
Per FAQ here: https://pygccxml.readthedocs.io/en/develop/faq.html#performance If I add |
From cppyy docs, it looks like it does do lazy loading, and I'm not sure how to query all symbols. |
Added benchmark file: Latest run:
Closing for now, as I think 2x is fine for now given the differences. |
Re-opened and rescoped for comparing against |
This might be closable as "Not a Problem", but figgered I'd post it here anyway.
WARNING: These benchmarks are still relatively shallow. More work would be necessary to draw meaningful conclusions for more general usage / scalability.
New Setup:
pygccxml
vs.clang.cindex
Tinkering more, if I turn this towards a more complex project, like
CastXML
itself, and I want to see the CastXML symbols itself, it takes about ~70s to load a parsed file (from scratch) forpygccxml
, vs. ~3.5s forclang.cindex
.Example:
https://github.com/EricCousineau-TRI/repro/blob/3c2fbae3cb0afd623a2d7909e3f77f14fd67da52/python/bindings/pygccxml_sandbox/test_castxml_scan.ipynb
Uses:
libclang-9-dev
(9-2~ubuntu18.04.2
)CastXML@3e9bc94
, from superbuild downloadSpeculations for newer setup:
clang.cindex
at present.Old Setup:
pygccxml
vs.cppyy
With some simple code like this:
It takes about 0.60s on my machine for
cppyy
to parse this and allow me to print out a namespace object, whereaspygccxml
(withcastxml == 0.3.4
) takes about 4.3s. (This is across 10 trials, only timing the parsing + retrieval routine)Will post benchmark shortly.
Speculations:
std
andEigen
to see if that saves any time.cppyy
does any aggressive "crawling" through the namespace; perhaps it only does reflection on-demand?The text was updated successfully, but these errors were encountered: