Skip to content

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

@ihumanable

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.

Metadata

Metadata

Assignees

Labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions