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

speedup of pluggy #322

Open
9 tasks
RonnyPfannschmidt opened this issue Aug 16, 2021 · 3 comments
Open
9 tasks

speedup of pluggy #322

RonnyPfannschmidt opened this issue Aug 16, 2021 · 3 comments
Assignees

Comments

@RonnyPfannschmidt
Copy link
Member

there is multiple levels of speedups possible/for consideration

  • external tools (mypyc/cython)
  • the hook call mechanism (attr getter in c for the arguments)
  • setup/teardown of hooks
  • behaviour of the limited/scoped hook callers (subset callers used in pytest)

to better gauge impacts we need benchmarks stressing

  • nesting of calls
  • number of calls
  • number of plugins
  • surrounding tools like tracing/hook exclusion
  • number of arguments
@RonnyPfannschmidt RonnyPfannschmidt self-assigned this Aug 16, 2021
@wahuneke
Copy link
Contributor

Would you be interested in seeing a POC version using a 'dynamic code' approach? The concept here would be: at the first attempt to run hooks through HookRelay, we 'precompile' the whole stack of hooks so that less logic needs to be evaluated during the hook call and subsequent calls. Modifying the stack (by (de)registering plugins, etc) would invalidate the cached 'compiled' version.

By preprocessing / 'compiling' the stack we accelerate some of the slower aspects of calling hooks, specifically:

  • assembling the correct args for each hook's call ( a significant portion of the total overhead, I think)
  • multiple ifs and nested function calls and their associated attribute lookups

In my local, rough draft implementation, I was able to speedup benchmarks by 10-20% with only a small modification to the current code. More speed improvement is probably possible under this approach.

In some ways, I think, generated code is a great fit for what pluggy wants to do. On the other hand, I'm not sure it is ever a good idea to use it in a real project :P . Any thoughts?

@RonnyPfannschmidt
Copy link
Member Author

It's not quite clear what you mean by that,

Cython is currently Most likely to create a spedup

Certain refactoring need to be added first tho

@wahuneke
Copy link
Contributor

wahuneke commented Sep 27, 2023

It's not quite clear what you mean by that,

Cython is currently Most likely to create a spedup

Certain refactoring need to be added first tho

Sorry @RonnyPfannschmidt ! That was a terrible explanation. I've taken one more run at it. And, I've moved the discussion to a separate ticket in order to avoid polluting this one (issue #449)

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

2 participants