I'd like to profile my application which I've written in C# using Cloo as a wrapper for OpenCL.
I've tried a few things... gDEBugger, AMD APP SDK, CodeXL, KernelAnalyzer...
Copy-Pasting my Kernel Code as it is to KernelAnalyzer will indicate that the bottleneck are the ALU operations. However, since it's only a kernel analyzer I don't wholly trust the generated information.
To properly profile my application I tried the other tools. I tried to profile with APP SDK via console using sprofile.exe but I always get "Failed to start application: 0: the process has terminated successfully". I can't really guess what the issue might be.
When using the standalone tools CodeXL and gDEBugger I can see the Debugged Process Events (Threads starting, Messages) when running the .exe but that's about it. No function calls, memory info, statistics etc... it's all empty as if I didn't run the application! So it's basically useless for me.
I don't really know what the problem might be. Could it be that using Cloo as a wrapper makes all the performed operations invisible to the profilers?
I'd appreciate any hints! Thanks in advance!
I just tried to profile Clootils.exe (the sample that comes with the Cloo distro) with CodeXL, and after some trial and error, I was able to get CodeXL to work.
I had to first rebuild both Cloo.dll and ClooUtils.exe with the Platform target set to x86. Using the default setting of "Any CPU" gave me a "The application was unable to start correctly (0xc000007b)." error. Trying "x64" gave me a "Failed to profile" error message, and left the ClooUtils.exe process in memory. But trying with "x86" allowed me to profile just fine. I tried both "GPU: Application Trace" and "GPU: Performance Counters" profile modes in CodeXL, and both worked.
So that may provide a workaround to allow using CodeXL.
Related
I am trying to make an Android app in Unity that uses some heavy computation, when I tried to publish it to the google developer console I got an error "This release is not compliant with the Google Play 64-bit requirement"
After some digging around I found that I need to change the Scripting Backend to IL2CPP Instead of Mono and un-select x86
Now Google lets me publish the app, but when I build and run it on my phone it is significantly slower, should I be worried about this? If so is there any way to fix this? (when I change Scripting Backend back to Mono and build and run the app doesn't lag any more when it's running, perhaps there are some different settings that I need to use?)
What I read so far was that the Scripting Backend IL2CPP is supposed to be faster as far as when the app is run, but at least on my phone this doesn't seem to be the case
The phone I'm using to test this is a ZTE Blade, Model number Z965 (I think it's called ZTE Blade X but I'm not sure)in case that's useful
I (might have) found the reason for the lag from this post:
https://forum.unity.com/threads/huge-fps-drops-from-60fps-armv7-to-25-30-fps-arm64-unity-2017-4-20.682018/
It seems that any logging operations take a long time using the ARM64 architecture(I ran the app using the ARMv7 and ARM64 architecture and the ARMv7 didn't lag that much) now that I changed every logging setting to "none" the app seems to run more smoothly(anyway at least I hope that was the only problem)
I've written an application in C# .NET with the WinForms UI toolkit. I'm attempting to provide Windows executables, but so far they simply don't work for anyone but me.
I'm creating the release packages by building the EXE and DLLs in Visual Studio 2017, copying them into one place, and putting that into a .zip archive. I'm not doing the fancy one-click publishing stuff.
The project is available on github (https://github.com/fadden/6502bench). The first person to try it got "<program> has stopped working" on Win7 (see issue). The second person was using Win10 Pro, and extracted some details from the event log that show it crashing in a system DLL (see issue). Both of them have the latest .NET framework installed.
I haven't worked with C# .NET outside Unity, so I'm a bit out of my depth. It's entirely possible I've skipped an "obvious" step, or am doing things wrong.
Update: answering some of the comments:
it's pure C#, no native or unsafe code
both people reporting problems confirmed that that latest .NET framework is installed (4.7.2)
the program doesn't seem to be starting at all, so I'm not sure what the app could be doing wrong as far as local paths go
the specific errors, including screen shots and log messages, are included in the issues linked above
the full source code, with the VS solution and projects, is up on github
The sense I'm getting from the comments is that what I'm doing isn't fundamentally wrong, so there's some devil in the details.
I downloaded the source, and debugged.
I received a StackOverFlowException on the following 2 lines of code.
ProjectView.cs
line 3545 : symbolListView.Columns[2].Width = lastWidth;
line 3719 : referencesListView.Columns[2].Width = lastWidth;
What is going on is you are handling the ColumnWidthChanged event on ListView components, and modifying the column width. This modification fires the event again, which is causing an infinite loop, and a subsequent StackOverflowException.
But why? I'll take a swing at an answer. You may have hard coded some values that line up with the DPI and resolution of your monitor. When the ListView instantiates on your machine, it doesn't have to 'redraw' the column with and does not fire the event, but for anyone else that doesn't have the same resolution and DPI, the event fires and causes the loop. I could be wrong, but sounds plausible to me.
we are deploying our application with ClickOnce and we noticed that when we start our application by clicking the ClickOnce desktop icon, the application start slower (it takes at least 30-60 seconds more) than while started directly from the .exe.
I've seen that it's not an unkown issue ( Slow startup of Clickonce winforms application after update ) but it seems it's still unresolved.
I'm wondering why that would happen and how to fix that.
I'm only using one machine so I guess it's not machine-related, not antivirus-related.
I'm noticing different memory management pattern during startup: the ClickOnce deployment takes more time and after a while it deallocates some memory.
We are still talking about 12 MBytes in difference ( 67MB via ClickOnce, 50 via direct .exe).
This is driving me nuts...
Thanks
I guess it's not machine-related, not antivirus-related.
You need to prove that hypothesis by installing the same anti-virus your client has on a dev VM. If you cannot reproduce the slow start up compare ProcMon traces between the machines.
I believe Hans is on the money and the anti-virus is the most likely culprit, as per the correct answer in the QA you refer to in your question:
I have seen very poor performance (minutes vs a few seconds) for a newly deployed first run .Net application is the users are running antivirus software as the antivirus tool checks the newly Jitted assemblies are not malicious.
Make sure you're using .NET Framework 3.5 SP1 or above as "there are significant performance improvements in the area of startup. Particularly with WPF applications" and 3.5 SP1 includes Splash Screens.
A Splash Screen could be a quick (temporary) fix. Alas, not an ideal solution.
ClickOnce is getting pretty old now and there have been a lot of advancements in this field so why not adopt another strategy with a different deployment mechanism, such as Windows Installer and an Update Menu in the app. I detail the steps to make an MSI installer to Install to same path when upgrading application.
If you want to be strict about everyone being on the latest version instead of ClickOnce it would be better to have a web service the app pings on start up and downloads and executes the update when a new version is released.
Also, take tips from Google in this area. You remember the Jeff Atwood article: http://blog.codinghorror.com/the-infinite-version/
If you dont use ClickOnce you can use things like NGEN AND bsdiff, possibly even Google courgette.
There's some other ways to speed up the startup of a ClickOnce application discussed here.
While this may not answer your question directly, hopefully it gives you food for thought on how to identify the root cause and/or use a different more up-do-date method for rolling out updates.
When you publish the build please choose the option of running the app in offline mode. Otherwise the clickonce installer will try to launch the app from your server rather than local exe.
Please let me know if there are any other scenarios need to look into or this helps.
Thanks,
I've read plenty of answers on here about how to deal with the error 0x80029C4A (TYPE_E_CANTLOADLIBRARY) that say that regsvr is the way to go and checking the registry to make sure that the dll I'm using is properly registered.
I've done all of this on computers other than my dev box but still nothing so here's what I have:
The DLL I'm trying to refer to was developed in VB6 (SP6) with the following settings:
Single Threaded
Upgrade ActiveX Controls
Binary Compatibility
I'm trying to reference it from C# using .NET 4.0 and it all works swimmingly on the machine that I'm developing on, however, when I try to use the project on any other computer that has the dll installed in exact same way I get the error above.
UPDATE:
This dll works fine, as I would want it to, when used from a VB6 application on all of the computers involved.
Can anyone please shed some light onto what is happening here and how I might solve it? I have the VB6 dll and can distribute it with my current project if that would help at all.
Many Thanks,
Gareth
I worked this one out I think... Foolish me was trying to use the DLL in a background thread and even though it was an STA thread it wasn't my friend.
I have a video capture (usb-webcam) application that currently uses very old VFW with p-Invoke hookup to C#. I'm trying to replace it and I stumbled on the VideoInput library, and later found VideoInputSharp. I managed to get VideoInputSharp into my application and it gives me the frame rate and camera control I need. The problem is that on some PCs the call to VideoInput.IsFrameNew() never returns true even though the device is set up (VideoInput.IsDeviceSetup() does return true).
I've successfully run this on a W7x64 system and a XPx32 system, but does not work on W7x32. Any thoughts on why this is happening?
UPDATE1:
Since originally posting this question, I've found that on the systems that don't work, I am still able to call VI.ShowSettingsWindow() to generate a dialog box; however, it is a different dialog box than I see on the systems that work (even though it is the same camera/driver). Is this a clue? Also note that I'm running the same version of DirectX on the machine it works with and the machine it doesn't work with.
UPDATE2:
The systems that this is failing on are W7x32 and W7x64 both using a Microsoft LifeCam. I found yesterday that if I remove the Microsoft LifeCam software from the machine it then works! I sure could use an explanation for that.