Are there potential drawbacks of ultra short polling duration in Fluent Wait in Selenium?

When using FluentWait in Selenium, it is possible to configure the polling duration of the FluentWait

As far as I know, that is the frequency of checking if the element exists, for example

So, if the timeout is 3 seconds, and the polling duration set is 250 milliseconds, the driver will check for element 12 times before ultimately throwing an exception when it checks for the element the 13th time.

To my understanding, and by that logic, decreasing the polling duration makes the script perform better because it will check for the element more times

Below you can find my implementation of the FluentWait

public static void waitForElementWithDuration(By locator, Duration duration) {
        FluentWait<org.openqa.selenium.WebDriver> wait = new FluentWait<>(Base.driver);
        wait.withTimeout(duration)
            .pollingEvery(ConfigurationManager.DEFAULT_POLLING_DURATION)
            .ignoring(NoSuchElementException.class, ElementClickInterceptedException.class)
            .until(ExpectedConditions.and(
                   ExpectedConditions.presenceOfElementLocated(locator),
                   ExpectedConditions.elementToBeClickable(locator)));
}

I am thinking about making the default polling duration in my configuration manager class shorter (right now it is at 250ms) Would there be any potential drawbacks of me setting the polling duration to 10ms? As the flow I am automating is rather long, and needs to be repeated for many times, implementing a shorter polling duration would make the total time needed to run the tests much shorter

I have been working as a Test Automation Engineer for 1.5 years, so I am still new, and would appreciate some help from more experienced Test Automation Engineers

Answer

FluentWait

As per the documentation, FluentWait is the implementation of the Wait interface that may have its timeout and polling interval configured on the fly. Each FluentWait instance defines the maximum amount of time to wait for a condition, as well as the frequency with which to check the condition. Furthermore, the user may configure the wait to ignore specific types of exceptions whilst waiting, such as NoSuchElementExceptions when searching for an element on the page.

Sample Usage:

// Waiting 30 seconds for an element to be present on the page, checking
// for its presence once every 5 seconds.
Wait<WebDriver> wait = new FluentWait<WebDriver>(driver)
    .withTimeout(Duration.ofSeconds(30L))
    .pollingEvery(Duration.ofSeconds(5L))
    .ignoring(NoSuchElementException.class);

WebElement foo = wait.until(new Function<WebDriver, WebElement>() {
  public WebElement apply(WebDriver driver) {
    return driver.findElement(By.id("foo"));
  }
});

The documentation also mention of a possible tradeoff as:

This class makes no thread safety guarantees.

---

pollingEvery

Again, as per the dococumentation, pollingEvery sets how often the condition should be evaluated. In realtime usecases, the interval may be greater as the cost of actually evaluating a condition function is not factored in. However the default polling interval is DEFAULT_WAIT_DURATION which is defined as 500L:

---

This usecase

Considering the above mentioned aspects, I don’t see any issues reducing the polling duration from it’s default value to 10ms or even 5ms which would reduce the framework execution time. The only concern being WebDriver is not thread-safe.