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

Performance improvements #5

Open
Boyan-MILANOV opened this issue Dec 20, 2021 · 0 comments
Open

Performance improvements #5

Boyan-MILANOV opened this issue Dec 20, 2021 · 0 comments
Assignees
Labels
core Maat core internals enhancement New feature or request

Comments

@Boyan-MILANOV
Copy link
Collaborator

Boyan-MILANOV commented Dec 20, 2021

Brain dumping about ways to improve runtime performance. The current bottlenecks are most likely:

  1. Expr creation: they require dynamic allocation and are thus costly to create.
  2. Disassembly/Lifting: seems that lifting is actually slower than execution, but I'm not sure whether that could be improved since we are using Sleigh for that
  3. Number class initialisation: if the mpz part has a non-trivial constructor it could hinder the perf gains that we expect from using Number for concrete values
  4. Expr canonisation: currently every expression is canonised upon creation. It certainly induces overhead, especially for memory operations that require using Expr. Computing expression hashes also adds overhead!

Some ideas to address them:

  1. Limit Expr usage as much as possible. Especially, we should not enforce the use of Expr for memory operations and be able to use Number too. Maybe we could consider creating a Value class which would be an std::variant<Expr, Number>
  2. Run some benchmarks/tests to verify this and look into Sleigh to see if perf can be improved. I wonder whether getting the register strings for translating PCODE operands to IR params causes overhead and if there is a way to do the translation without the string comparisons
  3. If mpz has non trivial initialisation, consider wrapping them in a class that enables to skip the init (std::optional maybe?)
  4. Two options:
    • We could canonise only when needed / when simplifying. The hash could be computed as part of the canonisation.
    • We could also skip canonisation entirely, but that would suppress some simplifications, and we would have to switch from ExprObject::eq() to comparing Expr raw pointers for quick expression equality (deep expr equality can be done with a recursive method on the arguments...)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Maat core internals enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant