Support getting the element cache size, clearing the element cache

[qmfrederik]

Every time a user finds an element using the element or elements route, a new XCUIElement object is added to the session cache. The elements are never removed from the cache.

A very naïve script which goes to the home screen and queries for the 'Phone' element 1000 times in a row, will cause memory consumption (as measured by Xcode) of the WebDriverAgent to grow to approximately 126 MB. Net, it appears that every XCUIElement object consumes about 100KB of memory.

For sessions which persist for a long period of time (say, 30 minutes or more), this can eventually lead to an out of memory situation in which the WebDriverAgent crashes.

This PR tries to provide an 'escape hatch' for applications which want long-running sessions, by allowing them to:

• query the amount of elements in the cache
• clear the element cache
  by adding two custom routes.

We're looking at other approaches to keep the cache size under control as well - e.g. by checking the element cache for duplicates and adding an option to remove 'stale' elements (elements which no longer exist); we'll try to submit PRs for that as well.

As usual, let me know what you think & happy to discuss further.

[mykola-mokhnach]

I'd rather use some existing caching algorithm, for example https://github.com/gn0meavp/LRUCache. Clients are not very likely to use such endpoints effectively and it would be better to rely on some built-in size measuring algorithm.

[qmfrederik]

@mykola-mokhnach If I understand you correctly, what you're proposing is to limit the maximum number of elements in the cache, and use an algorithm to decide when values are expelled from cache - in this case the least recently used?

I think that would work for us as well. Do you have any idea on what a reasonable initial upper size would be for the cache size? It seems very unlikely to me that any Selenium-based test would be actively using more than a couple of elements, so say 1024 elements would be more than sufficient?

Happy to make the change if @marekcirkos agrees & it's OK to import that code here.

[mykola-mokhnach]

I've just shared some of my insights. Marek is quite busy nowadays. You see, my PRs are waiting for months so we are committing into our own fork to get the changes ASAP.

[qmfrederik]

Ah, I see. You've been busy - even added the generic actions endpoint. Cool!

So, let me rephrase this then - if I were to implement LRU caching, would you accept such a PR in the Appium branch?

[mykola-mokhnach]

Of course. Just add unit and/or integration testing there

[facebook-github-bot]

@marekcirkos is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.