Add disclaimer to GitHub benchmarks script

[unalmis]

Should add disclaimer to benchmarks saying that they do not work well for measuring performance. For example in #1842 it says objective.compute performance decreases by 20%. In reality nothing has changed, and this noise is due to well known issues with github benchmarks . Developers can be misled unless this warning is printed with the benchmarks.

[f0uriest]

I'd rather just increase the number of samples in the testing to reduce noise.

[dpanici]

Disclaimer is fine. More rounds wont help the issue which is that the same task can take different average amount of time if I run it on the same hardware one hour later

[unalmis]

More examples of misleading benchmarks. This occurs for some test on nearly every PR. Here is another example of wrong benchmarks. Go to any other pull request and you'll see the master memory is 7 GB and 3.5 gb and it has never been 2GB. Yet the benchmarks claim that master uses 2GB. This is simply a bug in the benchmarks.
#1834 (comment)

[YigitElma]

There are 2 points here. Usually, when you see these kinds of memory benchmarks (1 branch uses 200Mb!) it indicates that the test has failed. Here what you see is that. Master fails, because you changed the name of the keyword argument, and benchmark tests try to initialize with the new argument that doesn't exist in master. I don't think there is an easy fix to this, I'm not even sure there is a hard one, either. Only solution is to use benchmarks*.py file of master for master benchmark, and the one of PR for PR benchmarks, but this is also misleading since they would use different tests (imagine you changed the jac_chunk_size for one). So, this is not a problem of running benchmarks on Github runners but another one.

A similar thing also occurred in #1842. Since the added argument to tests doesn't exist in master, it fails (but for that one, it was speed benchmarks).

The second point is (the actual problem), we don't check if the test functions completed without an error for the memory benchmarks. For instance, here, memory benchmarks give some results that are wrong, because it could only profile until the test fails. So, 200MB is just base memory usage of Python stuff, not the test. I didn't spend time to fix this, because normal speed benchmarks have very similar version of these tests, and if they fail there, you will definitely notice what is going wrong.

Memory benchmarks already have a disclaimer to check the plot, and there you will see that it didn't run the test properly. Also, if you go to workflow itself, it prints out the error. If someone wants to fix this for memory benchmarks, I can explain how the benchmark works, but it is not in my priority list for now.