Is there any reason whatsoever for huge performance issues after clicking an item that brings you up to another screen ?
I've successfully done some very nice and fast unit testing with appium in python over an android app. The problem is, everything works fast and fine, until I click an item that shows more products in a new screen. After that, every single call to self.driver.find_element_by_id or by whatever takes like 10 full seconds no matter what, before it was instant.
I did timing and performance testing, and after clicking the item with .click(), everything takes 10 full seconds to complete, which was instant before.
Is there any reason behind this that I'm missing ? Maybe because of switching to the new screen that might be a a different activity ?
Example:
self.driver.find_element_by_id("sticky") <= every call before this is pretty much instant
more_item.click() <= this click ruins everything
sleep(5)
self.driver.find_element_by_id("sticky") <= every call from now on, even if it's the same as above, takes 10 full seconds no matter what
instead of using self.find_element_by_id(***) use find_element_by_androidUIAutomator that will increase the response time of Appium for you.
Hope this helps.
Related
I'm trying to develop a rhythm game in Monogame. The notes are frame rate independent and work consistently over different computers, but the song playing does not. Right now I have it hooked up so the notes spawn and MediaPlayer.Play() do not start until I hit a key (so it's outside of loadcontent/initialize like I've seen other solutions suggest). The song does not start playing until I hit the "I" key (gets checked in Update). However, the song seems to start playing at different times across different devices. I pull down the project on both my laptop (on battery) and desktop, and hit the "I" key at the same time on both, and I get different results on my laptop. Sometimes it'll be seconds ahead of the desktop, other times it'll be a second or two behind (this is usually the case). It seems pretty consistent on desktop. I'd try more than a dozen times and everything is still synced, but not on my laptop. I'm worried this is something that works only on my PC but not on others.
I've tried enabling fixedTimeStep and setting FPS to 60 (and setting the TargetElapsedTime to the window title ensuring that they are indeed both hitting 60) and I still get inconsistent results. I've read from other answers about using PlayPosition from the MediaPlayer class, but that property is readonly so I'm not quite how I could use that.
At first, I thought my notes were simply dependent on frame rate, but after setting FPS and fixedTimeStep, and also holding my laptop up to my desktop monitor they match up perfectly. It's just the song not syncing up. I'm still a newbie to XNA but I couldn't find anyone else reporting different song starting timings like this. Any help would be greatly appreciated.
I thought of a solution the second I got out of bed the next morning. I figured there must be some overhead on MediaPlayer.Play(), but I wondered if I could start it, pause it, then resume instead. Turns out, there is a Pause() and Resume() method which is what what missing from making this work.
So! If anyone else out there is having similar issues, here's what I did. I kept a key to activate MediaPlayer.Play(), but immediately added MediaPlayer.Pause() after. Then I got another key to resume the song, and the notes spawned when the song was resumed. So pressing "I" played the song and paused it immediately. Pressing "R" resumed the song and started spawning the notes.
So, basically I'm trying to decrease loading times for an Action Extension I'm writing for IOS.
According to: https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/ExtensionCreation.html#//apple_ref/doc/uid/TP40014214-CH5-SW7
I should aim to get the loading time below 1 second (if it takes too long it might be shut down by the system prematurely)
Right now it loads in around 4 seconds on an iPad (a bit faster in the simulator) - so far iOS haven't shut down my extension, but this will be destructive for the user experience.
As far as I'm aware I don't have access to a AppDelegate.swift file when working with extensions, thus I'm having a hard time figuring out what is causing the slow loading times.
Does anyone have any idea where to look or maybe some experience with this?
Thanks!
The reason for the slow loading times was that I launched the app extension in debug mode. Running the app without the debugger it was significantly faster.
Did not consider this at all, but now it works like a charm :)
I am analysing an app's slow performance using iOS Instruments. To load a login page it takes around 25 seconds. In Instruments, the timer shows 25 seconds to load the page. But when I sum the running times of the call tree, It is just around 4 seconds only. I want to know where the slowness is occuring. Is there anyway to force instruments to show all the time taken in call tree?
Note: I tried Xamarin profiler also. It shows maximum time taken by any call as 1E-06 ms. Is there any way to know the time taken by the whole method?
Have you considered using the Stopwatch class? It is supported in Project Core Libraries and can be used in a high-resolution mode for higher accuracy. It would allow you to time the execution of a particular method (which sounds like what you are attempting to accomplish). You can find Microsoft documentation and examples here.
I am using GWT 2.4.
I am using Scheduler.get().scheduleFixedDelay(new Scheduler.RepeatingCommand() and Scheduler.get().scheduleDeferred(new Scheduler.ScheduledCommand() when needed.
For some reason, when I am debugging the website a timer fired event is being shown frequently even when I am in the login page(where I do nothing besides showing username and password).
Why is this happening? It is because of this, that the scrolling looks unresponsive.
Please note that I am remotely debugging the website by connecting my ipad to macbook.
Attached is a screen grab. Any help will be greatly appreciated.
When you say
a timer fired event is being shown frequently
Do you mean that the RepeatingCommand gets executed over and over ?
As soon as you call scheduleFixedDelay, the scheduler will execute the RepeatingCommand as long as the execute() method returns true.
I am in the login page
How about writing a log to see if the scheduled command you are talking about in the question gets invoked, even if you're not logged in ?
I found the reason for the delay. On each touch start I was getting all the text and applying a property like html.getElement().getStyle().setProperty("webkitUserSelect", "none") as part of my requirement. The data in that html is pretty big and to keep doing it on every touch start was causing a delay. Got rid of it now.
I have some problems in my iOS app.
I have checked timestamps in the touchesMoved with clock() function and use difference between current and previous values. Difference between 1st and 2nd events is greater than others.
Have you any ideas?
iOS is not a hard-realtime OS. There is generally no expectation that touch events will be delivered with regular frequency/uniform periods. You should not structure your app to depend on that. Events are delivered via the main thread, which could be delayed by other processing (drawing, etc.)
EDIT: If you're seeing huge differences in periods between the 1st and 2nd touches (relative to the periods between subsequent touch events), the first step would be to run the app in Instruments' Profiler template to see if some work that you're doing on the main thread in response to the first touch is causing the delay. If the delay is of your own doing, then fixing that is the first order of business.
Beyond that, you could try using various signal processing approaches to re-sample your data into uniform periodic data, but the problem is that any of those algorithms won't be able to deliver the first re-quantized point until at LEAST the 2nd (and more likely the 3rd or even later) event comes in, so if the principal problem is "The 2nd event doesn't come as soon as you'd like", then this won't help you.
Another good test: Try making an empty single-view sample app that does nothing but log the events as they come in -- if you see the same "odd" delay between 1st and 2nd touches in that trivial sample app, then that's just "how it is," and you can stop wasting time trying to change the OS behavior and move on to some different approach/solution.