[App Performance] Profile the time it takes for the app to execute the rules on the configs and generate the views

[dubdabasoduba]

Describe the enhancement

• The FHIR core performs a comprehensive initial sync. This sync gets the following items.
  • Application Composition resource (Based on the Application ID)
  • Application Congis referenced on the Composition
  • Patient data based on the sync configs

Implementation

• Review the time and device resources it takes for the application to execute the rules and render the view corresponding to the rules. Review the following views
  • Registers, Profiles mostly the ones with lots of rules added.

Device configuration

• RAM 3GB
• ROM 64GB

Expected results.

• Profiling documentation can be done by recording the following
  • Time and device resources it takes for each config rules to be executed and the views rendered
  • Amount of resources used by the device for each request. i.e RAM & CPU

[pld]

@ekigamba let's close this out with a performance test

[pld]

@ekigamba @dubdabasoduba below I've added notes on what I'd like to see to close this ticket and why I think it is worthwhile, please let me know what you think:

1. add a new test name something like "profile render test" in a folder named something like "performance tests"
2. add files for composition and needed configs (unless there are obvious ones to use already available), also OK w/this being written directly in the test file
3. in the test file start a timer, do the load operation with the files, end the timer, assert that it's less than some value, point it the CI, adjust the less than value upwards so there's a good amount of buffer
4. repeat for other operations (register vs profile, etc)

The idea here isn't to test that we're performing an operation in a reasonable amount of time, but to

1. test that over time we're not seeing drastic changes in relative performance, I think having the threshold be an order of magnitude above what we see on the CI is fine, I would expect 2x increase due to difference in run conditions to be normal, if we can tighten it down from 10x without getting flakey that's fine
2. have a set of tests we can then run in a controlled environement, e.g. on an emulator w/a defined amount of resources, usage running on a machine with the same to get less-relative measurements (emu better than CI, still worse than physical device)

[ekigamba]

Macrobenchmark tests setup is done and app runs without crashing.

Pending tasks

• Add UI tests for register and profile pages
• configuring these macrobenchmark tests to run on the CI
• Add documentation for running the macrobenchmark tests