Skip to content

Performance: Investigate persistent patching as a performance boost. #53

Description

@ihumanable

When a test patches multiple modules with many test cases it can lead to poor performance.

The current lifecycle of patching looks like this.

  1. On setup start a Patch.Supervisor with start_supervised which in turn starts the Patch.Listener.Supervisor and Patch.Mock.Supervisor
  2. For each module that gets patched, start a Patch.Mock.Server GenServer supervised by the Patch.Mock.Supervisor and then generate the Delegate, Facade and Original modules.
  3. On exit the Patch.Supervisor exits and shuts down the Patch.Listener.Supervisor and the Patch.Mock.Supervisor.
  4. The Patch.Mock.Supervisor in turn shuts down all the Patch.Mock.Server GenServers.
  5. Each Patch.Mock.Server GenServer has a terminate callback which restores the original module by purging the Delegate, Facade, and Original modules and recompiling the true original module.

The above can be quite time intensive, step 2 rewrite the abstract form for the module multiple times, for each patched module there are 4 modules compiled.

Possible higher performance strategy.

  1. Either globally or on setup_all start the Patch.Supervisor
  2. Allow patching to happen normally
  3. In setup register an on_exit which resets the internal state of the mock servers (unregister all mocks and reset the history)

This would mean that modules are only recompiled once either during the entire test run or at least a single test case.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions