This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Speed up a slow sleeping testcase.
ClosedPublic

Authored by sammccall on May 6 2022, 9:25 AM.

Details

Summary

This testcase runs slowly due to 3.2s of sleeps = 2 + 1 + 0.2s.
After this patch it has 0.55s only.

Reduced by:

  • observed that the last test was bogus: we were sleeping until the queue was idle, effectively just a second copy of the first test. This avoids 1s sleep.
  • when waiting for debounce, sleep only until test passes, not for enough time to be safe (in practice was 2x debounce time, now 1x debounce time)
  • scaling delays down by a factor of 2 (note: factor of 10 caused bot failures)

Diff Detail

Event Timeline

sammccall created this revision.May 6 2022, 9:25 AM
sammccall requested review of this revision.May 6 2022, 9:25 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 6 2022, 9:25 AM
ilya-biryukov accepted this revision.May 6 2022, 10:35 AM

Many thanks for improving the running time, this slow test has bugged me since the day I first ran it.
I'd even be happy to remove it completely. It's slow, possibly flaky, so IMO the corresponding check does not carry its weight.

I'm not sure if we introduced a new race condition there that will cause flaky test, see the comment.
Otherwise LGTM.

clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
272

This is potentially a race in the test that we did not have before, right?
There is probably much less work in the main test thread, but we probably can still see the failure if we are unlucky with how the OS schedules us.

My stance is it's better to have no tests for certain behaviours than flaky tests.
But if you find it useful let's try to run it and see whether my suspicions are unfounded, don't want to block the change on it.

This revision is now accepted and ready to land.May 6 2022, 10:35 AM

Many thanks for improving the running time, this slow test has bugged me since the day I first ran it.
I'd even be happy to remove it completely. It's slow, possibly flaky, so IMO the corresponding check does not carry its weight.

I agree in general, unfortunately this test is really valuable:

  • it tests something critical
  • it tests something tricky
  • it's the only test of that functionality
  • it's prevented real bugs in the past
  • I can't see how to replace it with reasonable effort
  • it doesn't seem to be flaky at all in practice => hard to justify an unreasonable effort

So I want to keep it, and I promise to feel bad about it.
(I think this is the only ridiculous sleeping test we have in clangd...)

clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
272

Yes-ish - it's the same thing as the race on the first updateWithDiags. In both cases we're hoping that the next event happens within 450/500ms so the debounce doesn't expire.

AFAIK this hasn't been flaky at all in practice (albeit at 1000ms), so until we have a better test (see above) I'd like to keep it :-(

This revision was landed with ongoing or failed builds.May 6 2022, 11:14 AM
This revision was automatically updated to reflect the committed changes.