I've been investigating performance tuning my Xamarin Forms application when running on an Android device using an Intel Atom CPU.
The largest performance I'm currently seeing is when loading a DataTemplate to set as the Content of a ContentView, this DataTemplate then dynamically loads other controls and DataTemplates within it to produce the UI of the application.
Running on this device from the signed APK archive, I am seeing the time taken from tapping on the screen to finish loading the completed UI of 3.9 seconds.
However, if I deploy the application from Visual Studio then run it on the device without the debugger attached, this same process drops to around 1.5 seconds.
It seems to be reliably triggered by the "Use Shared Runtime" option within the project properties. With this ticked I consistently see this process taking about 1.5 seconds, with it unticked it's up to ~3.9 seconds. This is the same regardless of application has been built in debug or release mode and regardless of the other settings within the project properties.
This particular scenario is the worst performing part, however I see all UI loading/layout processes improve by a similar ratio, displaying another view drops from 1.5s to 0.8s and so on.
As I am unable to create an archive with this setting ticked, what could be causing this change in performance and how do I get this performance replicated with it unticked?
I am running Xamarin.Forms 3.4.0.1008975, VS2017 15.9.4 and Xamarin.Android 9.1.4.2
Having Use Shared Runtime ticked selects all architectures in the Supported Architectures option in the Advanced window.
Unticking it removes all entries except armeabi-v7a meaning x86 is no longer selected. As it's now running an ARM application on an x86 CPU it results in the application running slower.
Ensuring x86 is ticked after unticking Use Shared Runtime gives the required performance when running on an x86 based device.
Related
I'm using Visual Studio 2019 on my Laptop that is connected to an external monitor. Both my laptop and the external monitor have a 4k resolution.
I'm facing a weird performance issue, where after every click/right-click the whole UI freezes for a couple of seconds. For eg. if I right click on a project, the UI completely freezes, not even the mouse moves and after 1-2 seconds I see the context menu.
My laptop is new and this happens only with VS 2019 and only when my laptop is connected to an external 4k monitor.
Anyone else faced a similar problem or knows a solution for this?
My Laptop has the following configuration:
Intel i7-10750H 2.60GHz
16GB RAM
SK Hynix PC601 M.2 SSD
GTX 1650 Ti Graphics Card
After a little digging, I found these options in Visual Studio. Turning them off seemed to do the trick:
Tools > Options and then under Environment > General deselect the following options:
Automatically adjust visual experience based on client performance
Use hardware graphics acceleration if available
If you want to go one step further, you could also disable the following option along with those above. (but in my case, just disabling those two seemed to suffice)
Enable rich client visual experience
Here's the GPU usage before and after disabling the options (for similar UI inputs).
Before:
After:
In the Before picture, the duration for which the GPU 3D usage remained consistently high is when the UI froze.
What I still don't seem to understand is why VS would need so much of GPU 3D computational power.
I am of recently developing a Xamarin based app in Visual Studio 2017 and I am not sure whether the performance I see at a build and debug time is what can be expected or if something is wrong.
Environment: imac late 2015, quad core i5 #3.5GHz, 24GB RAM.
I am executing visual studio (latest) under parallels 13 in windows 10 and have assigned all four cores and 20GB RAM to the VM (it doesn't make a difference though if I assign less).
The solution is a standard xamarin based solution with 3 projects and about 10 classes with roughly 300loc (yes really, there's almost nothing in there yet).
A rebuild takes about 1 Minute. Starting the application in debug mode takes about 30s for the simulator showing up.
Looking at the code size and hardware specs I was expecting build and simulation to be a matter of seconds.
Am I wrong? Even considering the VM I'd not have expected these numbers.
Is anybody able to share experiences/thoughts?
Your problem isn't simply compile time. Every time you build your project, your shared code gets compiled into a dll, code dependencies get checked, then linked into the native project, which is being compiled, resources get packed, integrity-checked and signed and is finally being bundled (not speaking of included nuget Packages and other plugins) and then the whole package gets packed into an app archive, which also needs time to be written.
Also your app gets transmitted to your device via USB or network (default would be USB).
Considering what is happening "under the hood", 30 seconds is quite fast.
However, I have found that the performance is less based upon cpu and ram (at least if your dev machine has a decent amount of both) but on the performance of your hard disk.
If you really want to speed things up, you might consider running visual studio and doing your compiling on a nvme drive (an alternative might be a SSD raid).
For instance I once had a xamarin app, which had a lot of dependencies on various nuget packages. Compiling the iOS Version took about 25 minutes (full rebuild) on a Mac Mini (2011 model improved with an aftermarket Samsung 850 Pro), switching to a VM solution running on a skull canyon NUC equipped with a Samsung 950 Pro nvme drive did speed up the process to incredible 2.5 minutes.
my app built in cocos2d. it works fine on simulator (ipad,iphone,iphone5) and also debug fine in my devices ipod 5th and 4rth generation but not working fine on ipad device(ios 5.1). i did recieve warrnings two times in my rootview controller. when i hit play button on ipad ipad just quits my without anything in xcode 'log'.
it just display 'Finished running APP'.
any suggetion about how or which is the best way to figuring out the bug.
Use Instruments and figure out how much memory you are using. Look at how much RAM you're using but also video memory with the Open GL ES Driver Profiler.
Check those numbers against the device specs. You will need to do different things depending on which type of memory you are running out.
Cocos2d manages a lot of objects especially Graphic objects and releases them automatically. If you are running low on RAM you should look at what big unmanaged objects you are using but also tiny ones that you allocate extremely often.
For Video Memory, do not use big 'empty' images (like background frames for menus), you can use a Scale9Sprite (http://www.cocos2d-x.org/boards/18/topics/8335) which will tile the center of that image.
This happens when your app runs out of memory; you need to reduce its memory usage and try again.
I'm developing a WinCE 5.0 application that uses two commercial libraries. When the application starts calling the second library it gets slowlier and then after some use, it hangs and the whole OS freezes. It has to be rebooted to work again. The thing is that I'm developing this without a physical device (a testing person installs each release and runs the tests) and without an emulator (the device provider is not facilitating an OS image).
My intuition tells me that the second library is using all the available resources (basically, handles and memory) for a WinCE 5.0 process. I have to prove this to the library vendor. So I wish to add to my logs some general process and system information. Could you recommend me which APIs to call to get this information in CE?
I would really appreciate any hint
Thanks in advance!
Windows CE provides a very robust set of APIs for a subsystem called CeLog. CeLog is what Kernel Tracker uses to collect and display it's information. You can get all the way down to scheduler calls and thread migrations if you want. The real danger with using CeLog is in collecting too much data so that making sense of it is difficult, but if you filter the collections to just your process, that should help. You could collect the data to a log file, then use Kernel Tracker to open and view that data.
Here are some good starting points for info:
Introduction to Remote Kernel Tracker
More on Remote Kernel Tracker
CeLogFlush.exe (particularly the section 'Collecting Data on a Standalone Device with CeLogFlush')
Implementing a Custom Event Tracking Library
Embedded Visual C++ 4 contained "Remote Performance Monitor" that could do just that. Microsoft retracted EVC4 as free download some time ago, but it can still be downloaded from MSDN or found on the internet.
With service pack 4 it should work for WinCE 5.0. It does not appear to work with Windows Embedded 6.0 and newer though.
When I try to debug an arbitrary CUDA application, e.g. the matrix multiplication or convolutionSeparable sample from the Nvidia GPU Computing SDK 4.0, I always get an output similar to:
Parallel Nsight Debug
CUDA grid launch failed: CUcontext: 2059192 CUmodule: 348912936 Function: _Z9matrixMulILi32EEvPfS0_S0_ii
……
……
And a file with the following content is showing up:
Parallel Nsight CUDA Debugger
The application being debugged with the Nexus CUDA debugger, was unable to
find any associated source. This could be for a number of reasons:
1) CUDA has not been initialized.
Make sure cuInit has been called, and it returned a successful result.
2) No CUDA contexts have been created.
Once a context is created, memory can be examined in the context. Each context
shows up as a single "Thread" in the Visual Studio Threads view. (Debug | Windows | Threads)
3) There are no active CUDA grids in any context.
A grid must be launched in order to hit breakpoints.
4) You have selected the "Default Context" in the Visual Studio Threads view.
This context is a placeholder shown when there are no available actual CUDA
contexts. It does not show real data.
5) No CUDA modules have been loaded.
You can see which modules are loaded in each CUDA context by showing the
Visual Studio Modules view. (Debug | Windows | Modules)
6) Symbolics were not found for the loaded .cubin.
The module needs to be built with debug information. Please specify the
-G0 switch when building.
7) A grid launch failed while running a kernel.
Each breakpoint within the corresponding “.cu” file is completely ignored during the run. When I just run the application, without Nsight Debugging, the program executes without any problems.
What can I do to tackle this problem?
My Setup:
1xIntel GPU and 1x NV 570GTX, I want to use the local debugging option
Win 7. Pro 64Bit
Dev Env.: VS2008 or VS2010
CUDA 4.0 & Parallel Nsight 2.0
NV Driver Vers.: 285.38
WPF is disabled
TDR is disabled
Windows runs in Basic mode (no aero)
Project Propertys: Cuda Runtime API -> GPU-> Generate GPU Debug Information -> Yes (-G0)
Firstly, you need to ensure that your display is driven by the Intel integrated graphics and not the NVIDIA GPU. This is because when you hit a breakpoint in CUDA code you are stalling the entire GPU, so if the same GPU was used for display then your system would lock up naturally.
Note that the hardware requirements for Parallel Nsight indicate you need two supported GPUs whereas you only have one, but if I understand correctly it's possible to use a non-Intel GPU for display (I haven't tried).
Assuming the above is working you should start by trying out the samples included with Parallel Nsight. You can find them in the Parallel Nsight menu group in the start menu.
CUDA Grid Launch has a wide variety of causes. This one is probably accessing an array beyond its allocated size. what in the x86 world is called a segmentation fault. i debug these by selectively commenting out parts of the kernel you are testing until the error goes away. (what we used to call wolf fence debugging). Another cause of grid launch failure is if the kernel is taking too long (1 or 2 seconds) to execute.
the reason the debugger isnt helping is that the debugger ONLY stops 1 thread in 1 block! your access error is coming before then. also you cant use the printf to find the bug as the output does not get returned in the event of a grid launch failure.
To add potential solution on top of the answers given already, one way to avoid the error is to run the NSight monitor with administrator right.
The answer for this is definitely using the correct driver for the installation of Parallel NSight. For the latest version (2.1 RC2, currently), this is driver version 285.86. For the current stable version 2.0, this is driver version 270.81, as another poster mentioned.