I have a Xamarin Forms application that I originally developed using Prism and Unity. I am finding Unity to be rather slow when first resolving an object though once that first time has passed all subsequent resolutions of the same object type are significantly quicker.
Based upon some unrelated advice I received on another thread I decided to try swapping from Unity to DryIoc. Unfortunately I am finding this to be even slower when resolving objects but without the speed improvement when subsequently resolving new instances of those same object types.
So, my question is this, is there anything that I can do with either of the containers that will improve the performance? For example...
Is there anything within Unity that will allow me to pre-configure
the objects that are likely to be created so that the first
resolution is as fast as the subsequent resolutions?
Is there anything I can do with DryIoc that will speed up all object resolutions?
For reference, my own usage of each is very simple; I am using RegisterInstance for most of my objects (settings, database etc.) and injecting them into my ViewModel objects through the constructors. The Forms and ViewModel objects themselves are all registered using the Prism RegisterTypeForNavigation extension method
First, you need to switch to UseInstance and check results.
Then ideally, it would be great to have a test of DryIoc vs Unity for specific use case.
Last, it may be related to this issue https://bitbucket.org/dadhi/dryioc/issues/453/migration-from-unity
The problems I was seeing were not related to the IoC containers but instead a problem with Xamarin that was introduced at the beginning of May with the 15.2 update of Visual Studio. Installing the latest update (15.2.26430.12) and rebuilding the solution restored the kind of performance that I was expecting.
Related
We're doing a rewrite of our UI using Angular 2. Since this is so new, there are very few resources available, so please excuse me, if my question seems silly and has been answered already.
First, a little background. Our product is built out of "modules" which are widgets that can be dropped on a page. Since, not all modules are being rewritten to use Angular 2, there will be a mix of non Angular and Angular modules on one page at the same time. For this reason, we've decided to make each Angular2 module to be a stand-alone angular app.
In the prototype phase all looked fine and dandy, however, fast forward a few months, and with just weeks before the release, someone looked at our page load times and was less than impressed. On my machine, with prodMode enabled, it takes 5 modules about 2.5 seconds to render with 2 of our most complicated modules taking a second each. The two biggest templates I've got are 32KB and 80KB in size, but since the processing time is the same, I suspect the linear length doesn't contribute as much as structural complexity, and they are pretty complex. The other 3 modules are much simpler.
From this timeline it seems that a lot of time is spent in parsing the template and loading components. So I thought maybe this is because each module is an independent angular app, and they probably don't share the cached components. So I've moved the BROWSER_APP_COMPILER_PROVIDERS from the App Providers into Platform Providers list. This caused all modules to reuse a single RuntimeCompiler (I think).
However in the grand scale of things, it did not improve the situation much. The total time went down to 2.3 seconds which makes it hardly worth the hassle.
Now, the modules are mostly wizards. That is they sit and look pretty until the user taps/clicks on the them to engage. So this got me thinking, what if I could stage the template parsing? If I could tell Angular to parse wizard steps on demand I could lower load time in exchange for some lag when interacting the the module. This is what I'm researching now, but I would love to hear the community's input.
Thank you for reading.
UPDATE: I am running RC.3.
In angular 2.4 we have a concept known as AOT, which can improve the performance!
An Angular application consists largely of components and their HTML templates. Before the browser can render the application, the components and templates must be converted to executable JavaScript by the Angular compiler.
You can compile the app in the browser, at runtime, as the application loads, using the just-in-time (JIT) compiler. This is the standard development approach shown throughout the documentation. It's great but it has shortcomings.
JIT compilation incurs a runtime performance penalty. Views take longer to render because of the in-browser compilation step. The application is bigger because it includes the Angular compiler and a lot of library code that the application won't actually need. Bigger apps take longer to transmit and are slower to load.
Compilation can uncover many component-template binding errors. JIT compilation discovers them at runtime, which is late in the process.
The ahead-of-time (AOT) compiler can catch template errors early and improve performance by compiling at build time.
Offline (pre)compiler could help, but it is not ready yet.
You could try replacing copy pasted/duplicated html code with separate component to reduce template size. Tree-like UI structure with reusable components might help.
Another way is to use lazy loading: load wizard when user clicks them (might use preloading).
I think it would be helpful to submit CPU profile to angular team, so that they could optimize compiler/parser.
Ok, Thanks for writing to me. So, if I am understanding this correct, every widget acts like different angular 2 app. Therefore, base module or base angular
app is dependent on multiple dependent injectable apps. Now, I am assuming this fact, that you have already taken bundling and minification of production ready
script. Apart from that, Just wanted to understand what is the SLA of API serving the request. Many a time, I observe that people complain UI for slowness. But,
it used to be the backend not meeting the SLAs. Check if your backend SLA is fine.
Next, what is your caching strategy of angular modules. How frequently, these are making request back to the server. Here is a catch. Around caching, all components
are not released in a battle ready status. Another thing, which I wanted to understand is, whether you are using RXJS for handling promises or not. RXJS, drammatically
improves the performance of angular 2 app.
Next, is reusablity of the code, say wrapping the reusable code in directive and then injecting the same at all the required places. This will cut the code compilation
cost.
Also, keep checking angular 2 milestones and the new fixes getting released around performance improvement. I am expecting final battle ready production framework
for angular 2 by December. Then, we will also migrate our apps to angular 2. Even, in nasdaq, we are currently running on 1.5X version. I hope this will help you
to improve the performance of your app.
I am creating one game in Windows phone using c# and silver light platform. I am new in this technology and currently facing memory leak issue.
As per research and study I have done, I have tried to do all the things including events, string and usage of garbage collector.
Can any one please give common tips to best utilize garbage collector and memory management since it seems issue right now. When my garbage collector reaches 5 lac size, it stop collecting new things and application is getting crash.
I also tried empty the garbage collectore passing parameter 0 in gc collect but it is crashing the app.
Can you please guide and help for basic things to take care, process to follow to avoid such issues and best use of GC collect?
Thanks in advance,
Jacob
In general, you should never have to call GC.Collect yourself as unused objects will be automatically collected every few seconds.
As for what can prevent objects from being collected, it comes down to them being "rooted". Roots include:
Any static references
Any references held by the run loop (your Application is the closest thing here)
Anything being displayed on the current page or any page behind it
Anything referenced by any of the above (including UI events), or referenced by anything that is referenced by any of the above (etc).
In the above scenarios, those objects and any objects they hold a reference to cannot be GC'd. So as for advice:
Avoid defining anything as static
Be careful how many objects are held by Application
Avoid a navigation model that allows your back stack to grow to ulimited levels
Potentially look at setting references to large data sets to null in your page/viewmodel's OnNavigatedFrom method and re-initialise them in OnNavigatedTo
I'd recommend using the Windows Phone Profiler, which comes with the 7.1 SDK. It will tell you what objects are in memory and why.
Without seeing any of your code, it is difficult to give specific advice.
However, I strongly suggest you run a memory profiling tool like ANTS Memory Profiler or .Net Memory Profiler. These tools will show you what portions of your code are never released and are very helpful in making the adjustments that you need.
I am currently trying to automate a Windows Forms application by using the Microsoft UI Automation Library and C#, but I have big problems concerning the performance. The Identification of single elements by using a PropertyCondition or iterating over all elements of a window takes very long (up to 4 minutes). As soon as I have a AutomationElement, everything is fine (e.g. GetCurrentPropertyValue reacts within 100ms).
The poor performance only applies to one application. I don't have access to the source but if something needs to be changed or checked, I can talk to the responsible programmer. As far as I know, some events (e.g. paint) were overwritten for the application. A typical window of the application contains about ~100 elements which are found by the FindAll method.
I also tried the COM interface of the UI automation library, which is about two times faster but this does not really solve the problem.
Does anyone have an idea how to solve this problem or experienced similar behavior?
We found the answer when we took a closer look at the main loop. In most cases Application.Run is used to start up the main window and run the application but for some reason the following code was used:
[...]
MainForm.Show();
while DoStop == false
{
System.Threading.Thread.Sleep(10);
Application.DoEvents();
}
[...]
As the Microsoft UI Automation Library uses window messages, all the System.Threading.Thread.Sleep(10); summed up and made the object detection become really slow. This does not happen, if Application.Run is used.
I have an app that is slow to start. I assumed it was because of all the various controls on the first page, but even after I removed all the XAML (as an experiment), my start time wasn't reduced (or at least not perceptibly). I then noticed all the various assemblies getting loaded one by one in the output window.
Obviously, adding anything to a phone application (with its limited resources) is going to affect performance. But at what point will adding dlls start affecting start up performance? If you create a new app in Visual Studio, you'll have ten references automatically. How many more until you have a performance issue?
I don't see how can just-references delay your start up time. Maybe you're actually using them (see for singletons or factories on your constructors, they tend to use more resources than expected ones).
Anyway I don't see a fix. You can not load assemblies on demand cause they must be signed and licensed by Windows Marketplace. (Assembly.Load is marked as SecurityCritical).
Are you trying on emulator or device?
I've got a WF State Machine which I use to handle page navigation on a WPF Media Center App. It's got a half-dozen states which each have Initialization handlers and one or two EventDriven handlers.
When you first make a StateMachine workflow using a VS template, you have the option of using a code-behind model, or a code-separate model wherein the workflow topology is described in a .Xoml (xml) file.
Lately, whenever I'm working with the State Machine, Visual studio intermittently hangs for up to ten seconds, after which it always recovers.
Might this be a problem inherent in the Xoml parsing that will go away if I redo the state machine using the Code-behind model?
Anyone have relevant experience regarding Workflow Designer performance in either model?
This is a well known problem with the workflow designer in visual studio 2008. We were promised improvements in sp1 (and supposedly got them, but I have noticed nothing). Suggestions include:
Move all types used in workflows to a different project than where the workflows live.
Move interfaces, event types, custom activities, helper classes to a different project than in which the workflow resides. E.g. in the solution from a customer, there were about 10 project, with 10 workflows each and 10 associated event types. These types are all reparsed to update to build the design time type information every time the user changes workflows in the project. Moving these to a different assembly e.g just one project with all the types needed for the 10 workflow projects will help improve performance.
Reduce the number of workflows in a project.
Each workflow is a type ( directly in c#/vb, and indirectly in xoml case) that needs a design time type to be built by parsing, so if there are 10 workfows in a project, opening any workflow in the project for the first time means parsing all the other workflows as well. Classifying these workflows based on their function and grouping them in 2-3 workflows per project improved performance drastically.
Re-Factor large state machine workflows into smaller workflows
One example we found from a customer had 780 states and 1000 activity binds in the same workflow, leading to a InitializeComponent() of about 16000 lines. Factoring this state machine into smaller reusable workflows will making designer performance much better, and reduce a lot of redundant states.
Don’t do long running work in activity constructors
Activity constructors are called during design time also, so doing things like connecting to a database etc should never be done in constructors, this can make the designer take too long to open workflow documents using these activities.
From: http://blogs.msdn.com/madhuponduru/archive/2008/09/30/workflow-designer-and-performance.aspx
-Oisin
VS 2008 was giving me the same unusably slow behavior you describe.
I've been working with that same WF project in VS 2010 (in a Win 7 RC VM) and performance appears to have improved considerably. At the very least, the diagram layout isn't getting lost like in 2008.
So maybe there's hope for the future.