I have created a demo app that applies multiple filters to an image (it is inside the project) and shows buttons in a UIScrollView with that images set as a background image. So, all the logic happens in a method that is called right from viewDidLoad. I'm not using any threading mechanism, so all the work is happening on the main thread.
I'm using Instruments, specifically Time Profiler to find out why the app launches so slow (it is obvious, but I would like to see it in Time Profiler).
When I run it I get the following result in the detail panel (in the root):
And when I press the arrow to see the actual code I get the following:
And this is for every filter operation.
Shouldn't the panel show the actual method inside of which I do filtering?
The main function is not the cause of your app being slow. In your screenshot the listing for main says you spent 0 seconds in main.
The Time Profiler instrument records the call stack 1000 times per second. The main function is the starting point for your app. That means main is going to be on the call stack most of the time your app is running, even though your app is not in main most of that time. The main function being on the call stack is the reason for the 649 ms and 95.5% listings in your screenshot.
Do not worry about the listing for the main function. You have no control over main.
If you want to find your functions in the call tree, select the Invert Call Tree and Hide System Libraries checkboxes. Selecting those checkboxes makes it easier to find your code in the call tree.
Related
I have given a wait time for 60 sec, and i am using wait until element to be clickable/visible but script is waiting for whole 30 secs even though the element is visible on UI and also clickable?
I tried using latest selenium version, tried using different waits also using different locators. but it did not work
The reasons could be in:
The element belongs to iframe so you need to switch to the iframe prior to attempting locating anything inside it
The element belongs to Shadow DOM so you need to locate ShadowRoot object, cast it to the WebElement and find the sub-element you want to click
Your locator is not correct, try getting the page source and saving it to a file. Once done use your favourite browser developer tools to locate the elemen
The syntax of your Explicit Wait is not correct. Check out Explicit Waits and How to use Selenium to test web applications using AJAX technology for code examples
Going forward consider adding page source and your code to your question as the chance you will get the comprehensive answer will be much higher, otherwise we have to go for "blind shots"
I know the basics of optimizing Robot Framework for speed on normal applications, but this is not a normal application. It's not a question of going as fast as possible, because if the code executes too fast on an Angular application, it'll try to click an element that isn't enabled or visible, or an element that doesn't exist yet. Timing issues abound, and the result is that I'm using a keyword (below) to slow down my program universally. The problem is that it's hard-coded, and I'm looking for a more "programatic" (programatical? I don't know the exact term) solution that will wait for an element to be clickable and then click it as soon as it is.
This is the keyword I use after every single click (${SLOW_TIME} is a global variable set to 0.5s):
Slow Down
# EXAMPLE USAGE
# Slow Down ${SLOW_TIME}
[Arguments] ${SLOW_TIME}
Sleep ${SLOW_TIME}
This is my current solution, which was written to verify that an element is ready to be clicked for test verification purposes, not speed. It's not complete (needs "Is Clickable") and occasionally causes the program to wait longer than it has to:
Verify Element Is Ready
# EXAMPLE USAGE
# Verify Element Is Ready id=myElementId
# Click Element id=myElementId
[Arguments] ${element}
Variable should exist ${element}
Wait until element is visible ${element}
Wait until element is enabled ${element}
I'm aware that Robot Framework isn't built for speed, but for long tests I'm tired of doing nothing for 10 minutes waiting for it to finish, only to see that I have an incorrect [Fail]. If the solution involves Python, Javascript, or Java, I can work that in.
EDIT: I'm currently using ExtendedSelenium2Library, but its implicit waits don't always work, so I wanted a second layer of waiting, but only as long as necessary.
First solution to explore would be to use libraries specifically designed for Angular based web applications, such as AngularJsLibrary or ExtendedSelenium2Library. As far as I know, ExtendedSelenium2Library is the one that works best (but perhaps not without any issues, I think it does have a few issues)
Next thing to know is, given that your element indeed is visible, it doesn't necessarily mean that it's ready to be clicked. There are quite a few ways to get around this kind of issues.
One way is to put a sleep in your test setup, to give the page some time to fully initialize. I'm personally not a fan of this solution. This solution also doesn't work well for pages that load new content dynamically after the initial document was initialized.
Another way is to wrap your click element in a wait, either by writing your own in Python or, using something like Wait Until Keyword Succeeds
I have a $http.put function that updates my database, this happens on a button click. After I update the database once, and stay on the page, with no interaction at all the update function gets called and will update the database with the last information that was inputted.
I've triple checked my code, there is only one occurrence of my update function being called. And the $http.put is inside $scope.update that is an anonymous function that calls the $http.put.
If I update information and then leave the page, and then come back the function does not fire on it's own.
Here is my Github for the project. I will pull out any specific code that you want to see, but I'm not sure what to show because there are 4 files involved. Those files are
(client/scripts/app.js)
(routes/products.js)
(public/views/routes/adminIndex.html)
(public/views/routes/modProduct.html)
Code is Here
Add a console.trace() just before the $http call to see what is calling it.
You can also use the developper console of your browser and add a breakpoint that will stop the code execution and let you inspect everything (stack trace, current context, etc). Chrome is particularly good at that.
I've been experiencing some problems with the ReportViewer. Basically the code is the following:
public void Display(object dataSource, ReportViewer viewer)
{
currentDs = dataSource as MyTypes;
if (currentDs != null)
{
var param = new LinkedList<ReportParameter>();
param.AddFirst(new ReportParameter("Title", "Title"));
viewer.ProcessingMode = ProcessingMode.Local;
viewer.LocalReport.ReportEmbeddedResource = ReportName;
viewer.LocalReport.EnableExternalImages = true;
viewer.LocalReport.DataSources.Add(new ReportDataSource(DataSourceName + "_Header", currentDs.Header));
viewer.LocalReport.DataSources.Add(new ReportDataSource(DataSourceName + "_Footer", currentDs.Footer));
viewer.LocalReport.DataSources.Add(new ReportDataSource(DataSourceName + "_Lines", currentDs.Lines));
viewer.LocalReport.SetParameters(param);
viewer.RefreshReport();
}
}
The problem is that sometimes it generates the rdlc report but others it just hangs the application. Specifically, it stays in viewer.RefreshReport(); forever.
The corresponding parameters and datasets are correctly set on the rdlc file.
Has anyone experienced a similar behavior?
Thanks in advance.
I suppose you have your viewer configured correctly.
Does the first time generation usually succeed? You could try calling viewer.Reset() after each report generation, that might solve some compounding issues.
There is a post from 2006 that on the surface appears to be relevant and might give you a workaround, although I have to admit I haven't done this myself because it would be almost impossible for me to recreate the problem you're seeing and so it would be equally impossible to see if any workaround would fix it. It's not ideal, but I'm hoping there no such thing as useless information :-)
The relevant info is at the bottom of the linked thread and for the sake of clarity, I've quoted it below.
The ReportViewer control is broken up into two components - the report objects (exposed as .ServerReport and .LocalReport) and the UI (the actual ReportViewer class). The report objects store all of the state about your report. The UI component simply calls into them to get the information it needs to display the report, parameter prompts, toolbar, etc.
The UI component is not thread-safe, just like most controls. But the report objects are thread safe. When you call RefreshReport, the viewer uses a background thread to call Render on the report object. But this is not the only time that the control calls into the report object. The first time it needs to compile the report definition (local report) or create a session (server report) can take a long time. If this "first time" is during RefreshReport, it will happen on the background thread. But as you have seen, it can happen at other times. Populating the parameters UI, for example, requires calling GetParameters, which also requires this startup penalty.
If you want to guarantee this "first time" penalty is on a background thread, then after setting the report path and other connection/data source information, call GetParameters from a background thread.
This seems to suggest that you make some calls to your ReportViewer always from a background thread rather than from the UI thread, so that any delays are not affecting the UI. It sounds like a bit of a bodged design to me though!
Is this of any help to you?
I may have fixed it. This page helped me figure it out: http://ikriv.com/dev/dotnet/MysteriousHang.html
So, it seems that a) report viewer needs to be created on the UI thread, and that b) that wasn't always happening reliably (see link for details). The report viewer is a .NET 2 component, and the behavior documented in the link applies to .NET 2.
To fix it, I employed the following tricks:
first trick: name the UI thread at start up
second trick: force a handle early on, then get a reference to the synchronization context
third trick: use the thread name and sync context to effect the invoke required -> invoke idiom.
If it all holds together, I will come back and post w/ more details.
I encountered the issue in Windows XP with .Net 4.0 and Report Viewer 2010. Yes the OS is end of support but Windows Embedded POSReady 2009 (Windows XP SP3), it's still in the extended support until April 2019.
To workaround the hang, call deprecated API to render the report
rptviewer.LocalReport.ExecuteReportInSandboxAppDomain();
and when exit or rerun the report e.g. report's parameters changed, the report need to clean up properly by
rptviewer.LocalReport.DataSources.Clear();
rptviewer.LocalReport.ReportEmbeddedResource = null;
rptviewer.LocalReport.Dispose();
// release sandbox is required to prevent the lock up, see below note on display report
rptviewer.LocalReport.ReleaseSandboxAppDomain();
// clean up report viewer
rptviewer.Clear();
rptviewer.Reset();
Note on Windows 7, 8, 8.1 and 10. The hang issue is not occurred.
I have an application which does some simulation, and renders the result. Because the render can sometimes be very slow, I separated it into another thread, and the main thread calls gtk_widget_queue_draw once it's ready. If it's not finished drawing yet, the extra requests get discarded (since queue_draw only invalidates it, and it's impossible to be "more" invalid).
The result is that with large complicated systems, simulation maxes out a thread, and render maxes out another thread, and everything works.
I just ran into a different problem, and I don't see why it's happening: A sufficiently simple simulation and render (6 5-point lines) causes it to break.
The first few (I've seen everywhere from around 60 to 400) steps render fine (in a fraction of a second), until one step renders twice. After that, it ignores the queue_draw, until I do something like drag a window over the render window, after which it restarts (until it breaks again).
If I artificially slow down the requests (usleep(10000) is around enough), this does not happen.
This is a completely unacceptable solution however, because the process of displaying is not allowed to interfere with the normal simulation thread (No delays, no mutexes, etc. etc.). I need a solution that makes the render thread do "as well as possible", given that it is working with volatile data. It does not have to be perfectly accurate--I really don't care if a frame renders a little wrong (half of frame i, half of i+1 is fine), as long as it does render.
Why is this happening, and how do I fix it?
You are having a race condition.
Since GTK3.6, you need to call gtk_widget_queue_draw like this:
g_idle_add((GSourceFunc)gtk_widget_queue_draw,(void*)window);
or like this:
gdk_threads_add_idle((GSourceFunc)gtk_widget_queue_draw,(void*)window);
where window is the GtkWidget* you want to draw.
Use the gdk_threads_add_idle if you're not sure whether libraries or code used by your app use the deprecated (since 3.6) gdk_threads_enter and gdk_threads_leave functions.
See: https://developer.gnome.org/gdk3/stable/gdk3-Threads.html#gdk3-Threads.description
Before GTK3.6, gdk_threads_enter and gdk_threads_leave had to be used to acquire the lock for GTK calls.
Did you locked UI calls in the threads with gdk_threads_enter/gdk_threads_leave ?
Maybe adding a code sample would help too...