Description
Motivation
With utPLSQL v3.1.4 - v3.1.6 some performance related issues were introduced. See #882 and #888. Fixing the issue required some collaboration with others, which worked very well. However, we should introduce a mechanism to avoid or at least try to avoid such problems in the future.
Feature Request
I suggest to write performance tests suites with the following main goal:
- compare overall runtime between utPLSQL releases (current / previous)
- running reporter consumer in the main process (after test completion)
- running reporter consumer in dedicated processes (during test run)
When running a reporter consumer in a dedicated process the overhead of a reporter (in most cases) should be reduced to something like an INSERT in the producing main process. In such a setup a reporter should never be the main contributor to the overall end-to-end runtime.
Technically I think the current development environment could be used for these performance tests. It should be good enough to identify relative performance issues between the current develop branch and the latest release. A dedicated shell script could do the job.