Loading dll files at startup is taking 3.5 seconds in our app. Does anyone know how can we reduce this time? Is it possible to delay plugins dll loading?
We are using Xamarin and Mvvmcross.
In Xamarin.iOS all dlls are loaded at startup before your code is executed, so I don't think you measured dll loading time, but something else that might look like it.
Without more data it would be mere speculation to say anything, so I recommend you use Instruments with the Time Profiler to see exactly what happens at startup and where the time goes.
If you run the app in debug mode you can see the initialization in the output window, and there you can see the libraries being loaded.
May be is not exactly the same process when you run the compiled app, but I think is probable that the delay in the startup is due to this initialization.
Related
In my Delphi application, when I execute TOpenDialog, it loads a lot of modules before showing the dialog.
This may take a while.(2-3 seconds).
The second and other times, it is much faster.
Is there a way to preload these modules when launching application?
The issue is not that the the modules take a long time to load. The issue is that the Delphi debugger instruments each new module load to report it in the output window.
The slowness you observe the first time the file dialog is shown is an artefact of running under the IDE debugger. If you run your program without the debugger then file dialog initial load time is greatly reduced.
Whilst you could track down the names of the modules that are loading, and force them to be loaded when the process starts, I would absolutely recommend that you do not do that. The modules that are loaded are likely to vary from system to system, so it is entirely possible that if you attempt to do this it will lead to you creating versions of your software that fail to start. Even if you do this just for your private debug builds, you will be guaranteeing that you suffer slower load times every time you debug the program.
We are developing a Prism application and starting the application under the debugger is pretty slow due to the loading modules procedure so we start the application and later on we attach to it.
Is there a way (macro, plugin, external tool) to attach to the application that is currently under focus? That would be very convenient.
According to some Research and my experience, it is not possible to attach the Debugger to the process whose window is in foreground. What may be the best solution for you, my friend, is the Just - In - Time Debugger. You can find more info here :
http://msdn.microsoft.com/de-de/library/5hs4b7a6.aspx
If you configure your application to use JIT, every time an error occurs, the following window will pop up : http://i.stack.imgur.com/gCBKq.png
Following Hans advice I've created a tool that exactly does that:
https://attacher.codeplex.com/
I hope it helps someone with the same need.
I am debugging a minidump file that is made when my application is starting. I am viewing the dump file in Visual Studio 2010. What are the "Modules" shown? Are they all loaded for specifically my application ? Or some are just generic, system wide modules ?
I am trying to determine if there are 3rd party modules/dlls that could be interfering with my application. I pointed out Sophos as an example in the dump. Could Sophos be intercepting disk write, or memory access and causing an issue with my application?
This is a commercial application that starts up fine, except for a few customer.
Thanks.
You are simply seeing the list of DLLs that were loaded in the process. The minidump is for a managed WPF application but you are also seeing all of the unmanaged DLLs. A minidump is fundamentally an unmanaged view of the process. You would get the same list if you debug your WPF app on your dev machine with the Project + Properties, Debug, "Enable unmanaged code debugging" option ticked.
And yes, that DLL you marked was injected by the Sophos anti-malware program. This is entirely normal, it is the way that they work. They absolutely do things like you suspect, mostly by hooking winapi functions, as the "detoured" name suggests. Detours is a Microsoft hooking library.
They are not automatically a simple explanation for a crash, although they certainly have a knack for destabilizing programs. Your program crashed with an access violation, you'll need to use the debugger to find out why. Not an easy kind of crash to diagnose btw. Good luck with it.
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 am having to use a 3rd party ActiveX DLL in my VB6 application. However, now that I've included the DLL in the references and used it in code, every time I quit my app, it also quits VB6.
I don't see anything in the logs or event viewer that would suggest why this is happening.
Is there anyway to prevent this?
Btw, I have contacted the vendor, but they are focused on their .NET products, it seems.
You may not be using the component correctly by missing specific initialization or termination calls, which has the affect of bringing down VBIDE. This usually happens when the third-party component or your application make Win32 calls.
I have had a few applications that I ran them through the debugger, they always terminated VBIDE. Yet, running the Release or Debug versions normally, resulted in the applications working just fine.
Try switching DEP off for VB6.exe only or altogether.
Also, this might be a license checking issue i.e. registry permissions -- try running VB6 IDE as Administrator (right click->Run as Admin)
I'm not a VB6 programmer by trade. I just mess around with the stuff. I have heard of this scenario referred to as sub-classing. Run a search on pscode.com. They have code and tutorial examples about how to prevent it. Good luck.
Ouch. I feel your pain.
Can you switch to a .Net component, and use it from VB6 via interop? I.e. write a COM-visible wrapper in VB.Net?
Just to close this question out... After spending significant time trying various things I ended up writing code that unloaded the control, paused for 5 seconds and then quit app. That seemed to do the trick.