patch icon indicating copy to clipboard operation
patch copied to clipboard

Performance: Investigate persistent patching as a performance boost.

Open ihumanable opened this issue 2 years ago • 0 comments

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.

ihumanable avatar Jan 01 '23 23:01 ihumanable