Webdriveragent: Appium 1.7.1 Automation is too slow

Created on 3 Oct 2017  路  31Comments  路  Source: facebookarchive/WebDriverAgent

I have updated Appium 1.7.1 from 1.6.4 and I observed that it is running too slow.
for me it took more than 5 minutes to run Enter Username, Enter Password and click on Login button
It was working fine with proper speed in appium 1.6.4

Appium version (or git revision) that exhibits the issue: 1.7.1
Last Appium version that did not exhibit the issue (if applicable): 1.6.4
Desktop OS/version used to run Appium: MacOS Sierra 10.12.6
Node.js version (unless using Appium.app|exe): v6.11.0
Mobile platform/version under test: iOS 10.0.1
Real device or emulator/simulator: Real Device
Appium CLI or Appium.app|exe: Appium CLI

https://gist.github.com/stephenws/a8ed795460d329af6fb95fc46c3def6e

Most helpful comment

Hi guys! I found the solution. Use the capability useJSONSource=true. It makes getting of source 2x or 3x faster.

All 31 comments

I am also noticing a huge drop off of speed using appium to test iOS when I upgraded to version 1.7.1. I would say that its almost 3x-4x slower now.

Do you use XPath selectors? Because from appium 1.6.5 and later the way that the Xpath selectors visibility is handled changed, introducing very big delays in Xpath. Appium 1.6.4 was fine.

See https://github.com/appium/appium/issues/8894

Yeah. For xpath selector automation stuck to find xpath,even for id it tooks time.

@ptsiakos77 I only use xpath on iOS when I absolutely have to. Most of my elements are found using the accessibility id or a predicate string. Furthermore I was using 1.7.0 Beta for appium and then upgraded to 1.7.1, and that is when I noticed the tests get slower.

I use 1.7.1 but I don't have such major performance problems. (except Xpath of course)

I had such kind of problems in the past but it was due to a bug MacOS Sierra wed driver polling mechanism to find elements. I had to append the computer hostname to etc/hosts file as a workaround like below:

127.0.0.1 localhost QAs-iMac.local
255.255.255.255 broadcasthost
::1 localhost QAs-iMac.local

But I don't believe that this is the case here.

It almost seems like there is an artificial pause in between commands now.

I found the issue also,the "/source" command is very slow,and if i request the command too ofter,the wda will crash.

It takes to long to response for /source and /elements endpoints.

Anyone got any solution on this?

We tried to checkout to an earlier commit but without luck.
Does anyone if we need to do anything else like building it manually or something?

It's time to add NSPredicate as the main type of locators!

@mykola-mokhnach Thanks for the link, I'll see if that speeds up my tests any!

So even after optimizing my lookups using the link that was provided, my iOS test still run slower than they used to. At the moment they take about 45 minutes to run compared to Android, which takes 20 minutes. These are the same tests between the platforms, and prior to Appium 1.7.1 they both ran in about the same amount of time.

Anyone knows about appium 1.7.0 feedback on Performance Speed issue. Because 1.7.1 is too slow so thinking about to downgrade appium to 1.7.0

Try 1.7.2@beta. We added some improvements there and also merged the recent WDA changes

Switching to 1.7.2@beta helped, shaved about 15 minutes off the running time for iOS. Down to 30 minutes now on iOS compared to Android's 20 minutes, so it's still not quite where it used to be, but definitely a lot better. Thanks for all the hard work!

@welnanick any other issues on beta 馃槈 ? i cannot deal with such slow performance. almost makes the tool useless for me. Thinking whether should go back to 1.6.4 or beta.

@welnanick just out of curiosity, how many tests are there for the 30 minutes duration? I am just switching to Appium from XCUITest; it is comparably much slower than running the XCUITest directly on XCode for me :(

@hardik-plume @raymondlapak Unfortunately I do not work for the company anymore that I was writing Appium tests for. Since I haven't seen the code base or used it in almost 2 months now, I can't answer your questions, sorry.

Hi guys! I found the solution. Use the capability useJSONSource=true. It makes getting of source 2x or 3x faster.

@Denys Zaiats it is still not working and it takes hell lot of time to grab the screen shot. Mine is a very simple screen with lot of bank names. Close to 200. It takes 15 minutes to grab the screen shot. Not sure how to move forward with this

I'm also facing similar issue. I tried using useJSONSource=true , but no improvement is seen. Any solution for this please?

This is pain. Clicking the "Allow" button on popup in bare safari takes up to two minutes, where finding by accessibility ID and clicking the element take both more than 40 seconds each.

I am facing the same issue with iOS app automation with Appium. It takes more than a 1m few seconds for a simple step such as a button click. And I am not using xpaths. I am either using @iOSFindBy(id="someid") or @iOSXCUITFindBy(iOSNsPredicate = "")
If any element is not present for which I check in 'if condition' it takes 20-30 tries before moving to next line which is making it extremely slow.
Any help please!!

Hi All,
I am also facing the same issue. Rendering of xpaths is to slow in iOS. I am using 1.8.2-beta version appium.
xcode version is 10.1
MAC is a High Sierra

I am too facing the issue of finding and executing commands to be too slow. I am automating an app in which a drop down has 400 listing. To scroll and select the option it's taking more than 1 hour rendering the tool useless to me. I am using appium 1.9.1 (CLI) and appium 1.8.2 (Desktop)... Has anybody found a solution for this?

Any Solution guys to speed up the test?

I'm getting particularly slow results when using the find_elements method. I tried setting implicit wait to 0 but it doesn't seem to do anything. Any ideas on what I could do about this?

I tried everything but only this helped
Just add capability: waitForQuiescence = false

Was this page helpful?
0 / 5 - 0 ratings