Form Speed Analyzer for Winforms - c#

I'm trying to help a friend speed up a slow winforms app (Don't usually work with winforms allot). I believe the majority of the issues are Database calls however there is quite a bit going on. For WebDev there are a ton of great apps to analyze Page Load Event, Latency's, and Bottlenecks. Is anyone familiar with and comparable tools for the winforms arena ?
Thanks All !

Any .NET performance profiler will tell you where the time is spent - there is one in certain levels of VS, and several commercial ones (JetBrains, RedGate).
If it is in a database call, you'll be able to work out which one, and look at that.
One problem I've seen in naive WinForms apps can be a lot of stuff being called more than once, particularly when a form opens - it's easy to hook some kind of 'changed' event on a control, which then fires when you're filling in a form, which in turn triggers more changes and then more events. Sometimes you've redrawn everything on the form two or three times before it all settles down. An instrumenting profiler which can track function calls accurately will show you this going on.

Related

Can using System.Timers.Timer in excess damage your application?

A have simple consol application game that currently uses a timer to draw the graphics every time the event is fired. Now that I'm comfortable with how the class is created and used, I would like to control the event time of other game aspects.
My question is, are there consequences to using too many timers in one application, or does it not matter as long as the events don't over lap?
If so, is there a better class to use to change the iteration speed of multiple items?
I did general research before asking, but am new to programming and might not of looked in the correct place. If the question is to cumbersome to answer here, can you recommend documentation to look at on my own?
Thank you for your help!
Game Development is not usually done in Console, WinForms or WPF. Game development has it's own approach in .NET (XNA) and approaches in .NET Core (https://www.microsoft.com/net/learn/apps/gaming). For certain cases and with very strong limitations it might work out, but it is usually not the best point to start.
Generally the worst danger of any code is "taxing out the CPU".
However unless I am mistaken, System.Timers.Timer might also use multithreading (it is hard to keep those 3-5 timers appart). Wich in turn opens you to the wonderfull world of Race Conditons: https://en.wikipedia.org/wiki/Race_condition#Software
Normally Consoles are immune to race conditons (purely sequential design) and at least GUI Systems are only slightly succeptible (nature of Event Driven System). But once you add Multithreading, the floodgates are open.
If this is an approach to learnign gamge development, starting with consoles is a bad idea.
If this is about learning C#, starting with a game that requires timers is a poor idea.

"On-the-run" Debugging/Monitoring

Is there a way/system to debug/monitor code without stopping execution?
In industrial automation control programming (PLC/PAC/DCS) it is possible to connect the debugger while the program is running, and see in the code editor the value of variables and expressions, without setting breakpoints or tracepoints.
As an example, let's have a F# multithreaded application, where code is executed in a continuous loop or triggered by timers. Is there a way to attach a debugger like Visual studio Debugger and see the values of variables and expressions (in the code editor or in a watch pane) WITHOUT interrupting the execution?
It doesn't matter if it's not synchronous, it's acceptable if the debugger/monitor does not capture all the code scans.
I am tasked to create an high level controller for a process plant and I would like to use C# or F# or even C++ with a managed or native application, instead of a PAC system. But being forced to interrupt execution to debug is a huge disadvantage in this kind of application.
UPDATE
First of all thanks to all for their answer.
Based on those answers, though, I realized that probably I need to reformulate my question as follows:
Is anyone aware of any library/framework/package/extension that allows to work with a native or managed application in windows or linux (C#, F# or C++) the exact same way as a PAC development platform, specifically:
1) Put the dev platform in "status" mode, where it shows automatically the runtime value for variables and expressions present in the code exceprt currently visible, without interrupting execution?
2) Create watch windows that show the runtime value of variables and expressions, again without interrupting execution?
Also, what I am looking for is something that (like any PAC platform) offers these features OUT OF THE BOX, without requiring any change in the application code (like adding log instructions).
Thank you in advance
UPDATE 2
It looks like there is something (see http://vsdevaids.webs.com/); does anyone know whether they are still available somewhere?
UPDATE 3
For those interested, I managed to download the last available release of VSDEVAIDS. I installed it and looks working, but it's pointless without a licence and couldn't find information on how to reach the author.
http://www.mediafire.com/file/vvdk2e0g6091r4h/VSDevAidsInstaller.msi
If somebody has better luck, please let me know.
this is a normal requirement - needing instrumentation / diagnostic data from a production system. Its not really a debugger. Its usually one of the first things you should establish in your system design.
Not knowing your system at all its hard to say what you need but generally they fall into 2 categories
human readable trace - something like log4net is what I would recommend
machine readable counters etc. Say 'number of widget shaving in last pass',..... This one is harder to generalize, you could layer it onto log4net too. Or invent your own pipe
With regards to your edited question, I can almost guarantee you that what you are looking for does not exist. Consequence-free debugging/monitoring of even moderate usefulness for production code with no prior effort? I'd have heard of it. Consider that both C++ and C# are extremely cross-platform. There are a few caveats:
There are almost certainly C++ compilers built for very specific hardware that do what you require. This hardware is likely to have very limited capabilities, and the compilers are likely to otherwise be inferior to their larger counterparts, such as gcc, clang, MSVC, to name a few.
Compile-time instrumentation can do what you require, although it affects speed and memory usage, and even stability, in my experience.
There ARE also frameworks that do what you require, but not without affecting your code. For example, if you are using WPF as your UI, it's possible to monitor anything directly related to the UI of your application. But...that's hardly a better solution than log4net.
Lastly, there are tools that can monitor EVERY system call your application makes for both Windows (procmon.exe/"Process Monitor" from SysInternals) and Linux (strace). There's very little you can't find out using these. That said, the ease of use is hardly what you're looking for, and strictly internal variables are still not going to be visible. Still might be something to consider if you know you'll be making system calls with the variables you're interested in and can set up adequate filtering.
Also, you should reconsider your "No impact on the code" requirement. There are .NET frameworks that can allow you to monitor an entire class merely by making a single function call during construction, or by deriving from a class in the framework. Many modern UIs are predicated on the UIs being able to be notified of any change to the data they are monitoring. Extensive effort has gone into making this as powerful and easy as possible. But it does require you to at least consider it when writing your code.
Many years ago (think 8 bit 6502/6809 days) you could buy (or usually rent, I seem to remember a figure of £40K to purchase one in the late 80s) a processor simulator, that would allow you replace the processor in your design with a pin compatible device that had a flying lead to the simulator box. this would allow things like capturing instructions/data leading up to a processor interrupt, or some other way of stopping the processor (even a 'push button to stop code' was possible). You could even step-backwards allowing you to see why an instruction or branch happened.
In these days of multi-core, nm-technology, I doubt there is such a thing.
I have been searching for this kind of features since quite a long time with no luck, unfortunately. Submitting the question to the StackOverflow community was sort of a "last resort", so now I'm ready to conclude that it doesn't exist.
VSDevAids (as #zzxyz pointed out) is not a solution, as it requires significant support from the application itself.
Pod cpu emulators (mentioned by #Neil) aka in-circuit emulators (ICE) and their evolutions are designed to thoroughly test the interaction between firmware and hardware, not so useful in high level programming (especially if managed like .NET).
Thanks for all contributions.

Efficiently creating many instances of a winrt metro control

I want to be able to create a few hundred instances of a winrt control (a search result control) in a C# project. The problem is that doing so takes too long (tenths of a second or worse) and must be done on the UI thread, creating stalls and delays in showing results.
For now I've bypassed the issue by pre-caching many instance of the control during startup. This approach works, but affects the startup time (profiling shows 40% of processor time near startup is spent caching these controls) and creates details to be managed, like the size of the cache.
I think the issue is that every time the control is instantiated redundant work, like re-parsing XAML, is done by the underlying framework. Maybe there's a way to avoid repeating this work? Maybe I can cheaply clone an existing control? Does anyone have ideas?
You could do the pre-caching in a parallel thread. Will make less of an impact on startup time on multicore processors
searchresult.memberwiseclone wil give you shallow copies. It might be faster, not sure
Could you use just one searchresult and fill it with the right data just before use? In that case there is no need to create a lot. Just use one as a re-usable container.
If the time is spent when adding the controls to the parent forms you could use
suspendlayout/resumelayout (this is win32)
setting parent to invisible and back to visible when you are done
Is there another way to do the same things faster? (competing control, 3d party etc)
Forenote: it's been awhile so Microsoft may have fixed the win8 app UI virtualization by now. I haven't checked.
What I ended up doing at the time was just hacking together my own UI virtualization to work around the issue. Basically: caching controls and re-using them to display the viewable data (using a binary search tree to efficiently query what can be seen). I wrote a blog post about it.

Update .NET desktop application in real-time

I have no experience building a .NET desktop application, all my experience is with the web. A friend of mine has asked me to do a quick estimate for a small desktop application.
The application just displays a list of items from the database. When rows are deleted/added from the database, they need to be deleted/added from the list on the user's desktop.
Is this done pretty easily in a desktop application, or do I need to do any sort of "reload" every X seconds?
The simplest design would involve polling the database every so often to look for new records. Adjust the number of seconds between polling to best reflect the appearance of real time and also for performance.
Any design that would allow the database management system to broadcast updates to a desktop application would be quite complicated and (depending on your needs) would most likely be overkill.
Elaborating on Andrew Hare's design slightly, I'd suggest that you include some sort of mechanism to 'short-circuit' the refresh cycle when user interaction occurs, i.e.
Refresh every x seconds
AND
Immediatey if the user clicks a control that is deemed to be a critical one AND the required update is less than x records
EXCEPT
where this would increase the refresh rate beyond a certain throttle value
Basically, you want to give the impression of high performance. Perceived performance doesn't mean accomplishing tasks quickly, it's more like doing the slow work during periods that you expect the user to be thinking, faffing around or typing something, rather than when they're waiting for a response. Very few applications are busy even a small fraction of the time they are running - any perceived slow performance is derived from a poor design where the program does too much work at once at the point the user asks for it, requiring them to wait. Caching in the background allows you to only assign the bare minimum amount of work to directly respond to user input, improving the user's perception of performance.
Trying to be directly helpful:
You state you're using .Net - which is handy. .Net databinding is very rich and powerful, and is quite likely to make this job a breeze.
However - read on...
There is a chance that it won't do exactly what you want. This is where databinding becomes a massive pain. Databinding requires certain things to be set up the way .Net wants it, and if they aren't, it's quite a lot of work reimplementing the basic functionality in the way you require. In this case, don't hesitate to reach for the MSDN documentation, and StackOverflow. Ask Early, Ask Often.

Debugging a performance issue on ListBoxDragDropTarget (Silverlight Toolkit)?

I have a complex project using SilverLight Toolkit's ListBoxDragDropTarget for drag-drop operations and it is maxing CPU. I tried to reproduce the issue in a small sample project, but then it works fine. The problem persists when I remove our custom styles and all other controls from the page, but the page is hosted in another page's ScrollView.
"EnableRedrawRegions" shows that the screen gets redrawn on every frame. My question is this: How can I track down the cause of this constant redrawing?
I have used XPerf to help track down performance issues related to redrawing in Silverlight. It is not completely straightforward or an easy process, but it can help point you in the right direction to where your problems are.
I started with a great tutorial by Seema about using the XPerf command-line tool to profile CPU usage for a Silverlight app. You can basically load up your app, start sampling with XPerf, perform your CPU intensive operations, and then stop sampling and analyze the profile XPerf generates. When you look at the XPerf charts you can select can filter by some process (such as iexplorer or your browser) to see the total % CPU. You can then select a specific length of time in the profile and drill down to see what functions from which DLLs are taking the most CPU cycles. If you point XPerf to Microsoft's symbol server you should get the specific names of the functions where the app is spending most of its time.
For a Silverlight app it's most important to look at what's going on in agcore.dll, npctrl.dll, and coreclr.dll. If your performance problems are related to redrawing, most of the CPU time is likely spent in agcore.dll since that does most of the graphics related work for Silverlight. You can then drill into that and see the specific functions in agcore.dll that are getting called most often during your sample time.
I understand it is kind of an annoying way to debug since you can only really see what is going on in the core Silverlight functions, but it may be able to help you figure out what is going on. In my case I was able to see that most of the time was spent calculating drop-shadows in agcore.dll. I was then able to figure out I stupidly had some content within a drop-shadow effect that was changing many times a second and causing constant recalculation/redraws of the entire drop-shadow effect.
Once you identify your redrawing issues you might want to look into GPU Acceleration with BitmapCaching if you haven't already. That will help offload some of the redrawing to the GPU and save you some CPU cycles.

Categories