patch
patch copied to clipboard
Performance: Investigate persistent patching as a performance boost.
When a test patches multiple modules with many test cases it can lead to poor performance.
The current lifecycle of patching looks like this.
- On
setupstart aPatch.Supervisorwithstart_supervisedwhich in turn starts thePatch.Listener.SupervisorandPatch.Mock.Supervisor - For each module that gets patched, start a
Patch.Mock.ServerGenServer supervised by thePatch.Mock.Supervisorand then generate theDelegate,FacadeandOriginalmodules. - On
exitthePatch.Supervisorexits and shuts down thePatch.Listener.Supervisorand thePatch.Mock.Supervisor. - The
Patch.Mock.Supervisorin turn shuts down all thePatch.Mock.ServerGenServers. - Each
Patch.Mock.ServerGenServer has aterminatecallback which restores the original module by purging theDelegate,Facade, andOriginalmodules 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.
- Either globally or on
setup_allstart thePatch.Supervisor - Allow patching to happen normally
- In
setupregister anon_exitwhich 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.