I have a main page in an app that has significant issues when the page is navigated to. I finally narrowed the issue when I added a static class that can be used to write trace information, and time elapsed to the debug out put. I have discovered that when this main page of the app is navigated to (always via hardware back, or nav.goback()) has a greater than 4.5 second delay between the OnNavigatedTo and the Loaded event. At that point, I cannot see any other places in managed code where I can add trace statements to drill down further.
Any suggestions on troubleshooting?
I would try eliminating (commenting out) various items from your XAML until the problem is greatly reduced or eliminated. Likely candidates are databound fields, listboxes, pivot controls with too many items, pivots within panoramas, Converters, etc.
Once you find the source of the slowdown you can begin to work on the cause.
Related
I am currently updating my app, and I have been facing a very strange and complex problem for the last few days. The part of the application that is problematic is made of one UITableViewController that is a list of news, and (after you click on a news) a detail view which is in fact a UICollectionView with as many details CollectionViewCells as there are news.
Each of these can have an infinite amount of elements, and are loaded 20 by 20 when the user scrolls to the bottom of the TableView (or to cell that is at the furthest position right on the CollectionView). Also, inside a DetailsCollectionViewCell, there can be another UICollectionView, containing images.
My problem is that after scrolling a few details views, after behaving normally (ie memory is allocated when I change the page, then stabilize until I change the page again, and so on), the memory allocation start to ramp up slowly but steadily, even if I stop doing anything at all. Also, the CPU usage will go to 100-120% and stay there, whatever I do, even, again, if I don't touch anything. After a while, the UICollectionView and the UITableView will not render any animation anymore, thus loosing the paging, and the inertia when scrolling, and overall resulting in a very poor user experience.
The strange thing is, I can observe these behaviours via XCode 5's Debug Navigator, but when I try to use instrument to find the source of the leaks/allocations, the allocation graph is normal, and I get 40-60 MB mem usage, no more, despite still observing the animations/paging problems.
Has anyone already met such a strange behaviour, and can someone help me in finding the cause of all this fuss ? (maybe by fixing Instruments ?)
Thank you all in advance, don't hesitate to ask me for more infos if needed !
I found the solution to my problems in the meantime.
About the difference in Memory usage between Xcode 5's Debug Navigator and Instruments, it was caused by my use of NSZombies. I have the habit of always setting them on, and that just flew off my mind... To remove them : Product > Scheme > Edit Scheme > Diagnostics > Enable Zombie Objects (just unmark it).
The cause of my CPU usage was an animation that was going on indefinitely in the background on multiple pages. The solution was to first of all stop it as soon as it is not seen/useful anymore, the optimise it by changing my approach (I was using CAAnimation and moved on to using UIView's animate function).
I think I might have pulled the trigger a bit too fast here, but hey... if this can help someone later, then it will not be a waste !
We build complex enterprise application using KnockoutJS and faced poor performance especially in IE8. Application might take more than 1GB of RAM and never frees memory. During investigation we discovered that KnockoutJS keeps references to the DOM nodes and never deletes it. This can be reproduced using IESieve against any public KnockoutJS example, just watch DOM utilization while playing with example which adds and deletes DOM nodes.
Have anyone faced this problem and has any ideas of how to work this out?
We had faced similar issues with knockout JS on IE 8. One of the problem areas was having an observable array (with 500+ elements) and building a UI (imagine a table like or list like structure) with all of those.
The only work around that worked for us was to change the view model so that it contains only very few items that could fit on the screen. Also, we had to add handlers for scroll events so that the observable array would keep getting refreshed. And (not too proud of this), we had to add an empty div at the top of the displayed records to give an illusion of the view having scrolled.
Probably to do with event bindings not being released when their DOM elements get deleted. If it's something thats happening under the hood with knockout, you will have to patch and submit a pull request.
I've had this kind of thing happen a lot with backbonejs too. JavascriptMVC is a bit better for cleaning up after itself.
I am working with flex for the last two years on some desktop apps. Until now I never had any performance related issues but today as we completed a mobile application for the iPad, I'm facing a challenge, the application is incredibly slow on the iPad.
http://i.stack.imgur.com/qkbWn.png
Slow, means that when I press a button in the menu to change the splitview I must wait something like 5s. Then scrolling is really slow two, with less than one fps and my TextInput starts to bug (the text is not in his box anymore).
I started to read a lot of blog post and presentation about optimisation for the mobile platform and then I rewrite some of the components I use. I removed the SkinnableContainer for instance and replaced it by a VGroup including some actionScript based drawing.
Now what you see is a VGroup (the dark grey one) containing some others VGroup (the group with title here) and then each widget is an HGroup with a label and a Widget. I only use Label and TextInput for the text.
Creation time is slow even (several seconds to create the view) for another page where there is only 4 text widget on it, or another one with only a list with a custom item renderer where each row is a set of 4 labels.
The whole things is cabled with RobotLegs, with nothing fancy, one models is injected in the view and at the beginning I set a member variable on the view with this object to bind my variables.
Frankly my thinking right now is : it smells fishy because if I've done everything right it is impossible to have such low performance and thinks that flex is competitive on the mobile platform. So right now I'm trying to disable the application piece by piece to try to locate what could slow it like that. I've got a couple suspects to check, for instance I've got some binding warning to check, and then see if robotlegs has got its share of the problem.
So my main question here is what do you think, and could you have some ideas about "is there a problem" and "how do we solve it".
Thanks
Run profiler for startup and separatelly for each operation that takes longed that it needs. Then prioritize the problems and try to solve them with basic optimization techniques.
Some problems you will not be able to solve fast - e.g. time for creating big components. The only option there is to rewrite those components with AS3 without MXML, styles and anything. I'm sure that flash.text.TextField is created many times faster than mx.controls.Label. The same for other components.
When component is created, it can be reused at a very low price. In your app there must be a lot of places where you recreate while you can reuse old components. It will save you memory and time.
Layouts tend to redraw even when it's not needed. If you have a lot of nested layouts, find the most critical places and replace a series of layouts with one custom layout or even component.
This all is very developer time consuming. At the end you will not get a smooth app anyway, but I believe that it can become usable.
I'm trying to determine some testing strategies for a Silverlight application of ours.
What I'd like to determine is the total time it takes for a grid to load and show data in the client. I've tried to put a timer round assigning the itemsource, but I need to know how long it takes the browser is finish loading the data into the grid.
Is this at all possible? If so, in what direction do I've to search?
This might help an article on MSDN "Loaded event timing in Silverlight"
http://blogs.msdn.com/b/silverlight_sdk/archive/2008/10/24/loaded-event-timing-in-silverlight.aspx
I think the main idea is to make use of the LayoutUpdated event. Since the event hangs off the FrameworkElement object I guess you could add a handler to all controls and effectively profiler all the framework elements of your Silverlight app. Something similar to the MVC Mini Profiler (SO uses/created this). http://code.google.com/p/mvc-mini-profiler/
I would certainly explore the LayoutUpdated event further.
I have a page in my WP7 app that I build dynamically. I create and add 60 user controls to a grid and it takes around 5 seconds. I need to find a way of speeding this up.
The process is as follows:
Create user control
Add new grid row definition
Set the value of the control row property
Add the control to the grid.Children collection.
It is step 4 that is taking the time. I'm guessing that each time I do this the visual tree is getting re-built.
Is there any way of telling the grid to only re-build the visual tree after I have finished updating the children collection?
Or is there another better way of doing this?
UPDATE: The List Picker control from the WP7 Toolkit was causing the problem. When I changed to one I wrote myself the time taken to display the page on a phone reduced from 25 seconds to 1 second.
The/your aim is to try and reduce the number of times you update the visualtree.
A few suggestions:
Try including (some of) the items in the page by default but just change their visibility depending on what you need.
Build the whole grid in code and add it to the page in one go (rather than a line at a time)
Depending on your content, you could try using a ListBox and alternating the template used for each row to get different content displayed.
The technique which will be best for you will depend on what you're actually adding to the UI. You'll need to test to see what is best for you.
If the UI virtualization (i.e. ListBox) helped, the problem must be in your controls. Templating, bindings, converters, using Xaml instead of C# code, unnecessary Xaml constructs (such as element names), overcomplicated visual tree (e.g. unneeded grids) etc. - those are the things that can degrade the performance.
If you suspect incremental visual tree rebuilds (I don't think so), then simply debug MeasureOverride/ArrangeOverride methods.
I guess this article might give you more tips. I described there how we optimized a similarly complex control - MonthCalendar with 126 sub-controls. Control load time decreased approx. 5x!