On Fri, 20 Mar 2026 22:31:35 GMT, Andy Goryachev <[email protected]> wrote:
>> I don't think there is a good way to test that. In the past, we instead made >> sure that all the branches are covered by tests that were optimized. >> We could probably measure the timing and have an arbitrary value we check >> against. But I'm not sure this is really needed. > > Hmmm, maybe we should check for the absence of quadratic complexity. > > For example, if the T1 is the time to perform an operation for 100 items, > then test that the time for 1000 items is below 0.8 * 10^2 * T1 (10 comes > from 1000/100). > > The goal is to make sure some later, unrelated change does not cause loss of > performance. Performance tests should not be regular unit tests that run with CI, as they will fail your build on hiccups. Also, if the test is to be of any relevance, it probably will be a slow test, directly adding a ton of time to each future build (even if it is only 10 seconds, having a 100 of those will add up). Such tests are better marked or kept separate and only run periodically, preferably on bare hardware (no other processes or containers) to get some reproducibility. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2118#discussion_r2969386451
