In my Mono (C#) project that is meant to be cross-platform, I am using the GTK for the UI. However one thing I noticed is, on my netbook in Archlinux, the performance is really speedy, so events such as mouse hover, and redrawing of widgets, etc, are really fast.
Compared to windows (7) on dual core CPUs, the performance is really really weak. Which perplexes me.
Am I doing something wrong that is warranting this difference in performance between OSes?
What are some ways I can do to optimize GTK on Windows? Its really bad to take around 0.5 secs for a hover event to kick in whereas its almost immediate on a weak(er) netbook with Linux.
My code is here for the GUI layer: http://code.google.com/p/subsynct/source/browse/branches/dev/subsync#subsync/GUI
Thanks!
The real problem is with the Graphics Library GTK uses. Cairo. You are right in saying that GTK performs a lot better on Linux and other Operating Systems as compared to Windows. That suggests that in fact the problem isn't actually with the entire Cairo Library. It is in the Win32 backend of Cairo. According to the Backend-Info in Cairo Docs; Cairo uses xlib and in some cases cairo-gl (think customized OpenGL) to work with on Linux and other platforms. While on Windows it uses Win32 GDI which, after all is a bit slow and outdated (not to mention completely software rendered).
Still, even this doesn't account completely for the poor performance of Gtk on Windows. Another problem may be that instead of using native Widgets, Gtk prefers to draw it's own widgets which look the almost the same on all platforms. However on Windows it also tries to emulate the native widgets using LibWimp to further increase native look and feel. This extra Windows-only step may also account for performance overhead. To see this for youself, try deleting (or renaming) libwimp.dll in the GIMP directory. GIMP runs a lot faster after that (though looked a little non-native).
There are also other smaller factors that may or may not affect Gtk's performance on Windows, like the fact that GTK has an extra runtime with like 12-15 extra dll's compared to other toolkits which have like 1-2. Dynamically Linking the entire Gtk Runtime may greatly increase startup time. There is also the fact that Gtk uses a lot of other libraries like Glib , Pango , and of course , Cairo . Writing glue code for these libraries also adds a lot of overhead , and sometimes even an extra library like Gdk .
To optimise Gtk you may try changing the backend of Cairo (difficult , unreccomended and requires another ton of glue code) or stop using libWimp (this will make Gtk look less native). But overall I think GTK is not that slow. I've never personally needed to use any optimizations. Even though I used WinApi in the past too.
I would guess that the performance problems are in Cairo. I suggest you use gtkparasite in Linux to see where and when parts of your app are being redrawn and optimize that.
You could also use the free CLR Profiler from MS on Windows to find the hotspots in your app.
Related
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.
Given that the familiar form of .NET is run on Windows, which is not a real-time O/S, and MONO runs on Linux (standard kernel is also not a real-time O/S).
Given also, that any memory allocation scheme offering garbage collection (as in "managed" .NET), and indeed any heap memory scheme will introduce non-deterministic, potentially non-trivial delays into an application's execution behavior.
Is there any combination of alternate host O/S and coding paradigm in which one can leverage all of the power and conveniences of C# .NET while implementing a solution which can execute designated portions of code within tightly specified time constraints? e.g. start a C# method every 10ms to a tolerance of less than 1ms, with completion time determined only by the work performed in the method itself?
Obviously, the application would have to be carefully written; time-critical code would have to avoid memory allocations; the application would have to have completed all its memory allocation etc. work and have no other threads active once the hard real-time loop is started. Also, the host O/S would have to support real-time scheduling.
Is this possible within the .NET / MONO framework, or is it precluded by the design of the .NET runtime, framework, and O/Ss on which it (or compatible equivalent) is supported?
For example: is it possible to do reliable fine-grained (~1ms) machine control purely in C# with something like NETduino, or do they have limits or require alternate strategies for such applications?
Short Answer: No.
Longer answer: The closest you can get is running the .net Micro Framework directly on Hardware, but the TinyCLR still doesn't give you deterministic timings. Microsoft has Windows CE/Windows Embedded Compact as their real time offering, but even that is only real time for slower tasks (I believe somewhere in the range of 50 microseconds or more - not sure if that qualifies for Hard Real Time)
I do not know if it were technically possible to create a real-time c# implementation, but no one has done one and even .net native isn't made for that.
Can C# be used for hard real-time? Yes
When we talk about real-time it's most often (if not always) about robotics and IoT. And for that we almost always go with one of these options (forget Windows CE and Windows 10 IoT):
Microcontrollers (example: Arduino, RPi Pico, NodeMCU)
Linux based SBCs (example: Raspberry Pi, BeagleBone, Rock Pi)
Microcontrollers are by nature real-time. Basically the device will just run a loop forever (there are interrupts and multi-threading on some chips though). Top languages in this category are C/C++ and MicroPython. But C# can also be used:
Wilderness Labs (Netduino and Meadow F7)
.NET nanoframefork (several boards)
The second option (Linux based SBCs) is a bit more tricky. The OS has complete control over the hardware and it has a scheduler. That way many processes can be run on just one CPU. The OS itself has a lot of housekeeping as well.
Linux has a set of scheduling APIs that can be used to tell the OS that we want you to favor our process over others. And the OS will do its best to comply but no guarantees. This is usually called soft real-time. In .NET you can use the Process.PriorityClass to change your process's nice value. Depending on how busy the OS is and the amount of resources available (CPUs and memory) you might get satisfying results.
Other than that, Linux also provides hard real-time capabilities with the PREEMT_RT patch, and there is also a feature that you can isolate a CPU core for your selected processes. But to my knowledge .NET does not have any API to use these capabilities (P/Invoke may work).
I'm writing an app, which is essentially a bunch of loose xaml screens - no codebehind, just dynamically linked to a ViewModel at runtime.
When running this over a weekend on an older pc, there was a crash. Tracing and recreating showed there was a memory leak in igdumd32.dll (An intel graphics driver dll). After a bit of investigation I wrote 2 simple standalone apps with a very simple animation in centre screen. 1 with no effects and 1 with a dropshadoweffect on the animation - no other changes, literally a 1 line change to the first app (xaml is quite verbose, otherwise I'd post it here). I ran these through redgate's memory profiler tool for 40 minutes. The 1st one was fine: but the 2nd one had a notable memory leak on igdumd32.dll and memory allocated by managed code:
Another thing I noticed is that this doesn't happen on a new pc. Looking at the versions of igdumd32.dll - the older pc has a 2009 version (8.15.10.1930) whereas the newer (working) pc has the 2012 version (8.15.10.2639).
Has anyone else experienced this? My thoughts are to only use special effects in xaml when the chipsets/drivers can handle this, but I can't find anything on the web or on MSDN that tells me hardware or driver limitations for these effects (beyond telling me that Hardware Acceleration is required for them or my CPU will bump up).
Your DropShadow and Blur effects in the earlier iterations of WPF were implemented in software (within WPF itself, that is) and would probably not have that problem of leaking memory. Later (4.0 and up) changed the syntax slightly and added the ability to off-load these effects to the graphics hardware. While that does enhance the execution-speed, it also becomes dependent upon the graphics driver to avoid leaking memory. You can change your code to implement these in WPF itself, or as you already have -- provide a hard-coded look-see to the graphics driver.
Is there any advantage to using C++ instead of C# when using Direct3D? The tutorials I've found for C++ and DirectX all use Direct3D (which to my knowledge is managed). Similarly, all of the C# tutorials I've found are for Direct3D.
Is Direct3D managed?
Is there any difference between using D3D in either of the two languages?
DirectX is entirely native. Any impression you may have that it's managed is completely and utterly wrong. There are managed wrappers that will allow you to use DirectX from managed code. In addition, DirectX is programmed to be accessed from C++ or C, or similar languages. If you look at the SlimDX project, they encountered numerous issues, especially due to resource collection, because C# doesn't genuinely support non-memory resources being automatically collected and using doesn't cut the mustard. In addition, game programming can be very CPU-intensive, and often, the additional performance lost by using a managed language is untenable, and virtually all existing supporting libraries are for C or C++.
If you want to make a small game, or something like that, there's nothing at all stopping you from using managed code. However, I know of no commercial games that actually take this route.
The point of Direct3D is to move rendering off the CPU and onto the GPU. If there were to be a significant performance difference it would be for that code that runs on the CPU. Therefore I don't see that there should be any significant performance difference between native and managed code for the part of your code that interfaces with Direct3D.
Direct3D itself is not managed code.
It depends on what you're doing exactly. As David Heffernan mentioned, one of the objectives of Direct3D is to move as much processing as possible to the GPU. With the advent of vertex shaders, pixel shaders, and much more, we're closer to that reality than ever.
Of course given infinite time and resources, you can usually create more efficient algorithms in C++ than C#. This will affect performance at the CPU level. Today, processing that is not graphics related is still mostly done on the CPU. There are things like CUDA, OpenCL, and even future versions of DirectX which will open up possibilities of moving any parallel-friendly algorithm to the GPU as well. But the adoption rate of those technologies (and the video cards that support it) isn't exactly mainstream just yet.
So what types of CPU-intensive algorithms should you consider C++ for?
Artificial Intelligence
Particle engines / n-body simulations
Fast Fourier transform
Those are just the first things I can think of. At least the first two are very common in games today. AI is often done in a compromised fashion in games to run as quickly as possible, simply because it can be so processor intensive. And then particle engines are everywhere.
I've embedded the LuaInterface project into an application written in C# using .NET Framework 4.0. After compiling LuaInterface and Lua 5.1 I've referenced them in my application and created a Lua VM and exposed a few .NET classes. When the Lua VM doesn't make many calls, performance is not affected at all; but when it starts to call a larger number of .NET functions the entire application becomes slow and unresponsive.
In response to this, I've made an additional thread to run the Lua VM on. For some reason though, the thread on which the GUI is updated will not update while Lua is doing a function call, resulting in stuttering in the GUI. When moving a window around, you can clearly see that it doesn't respond for a little while, then moves, doesn't respond, etc.
How can I solve this issue? I was under the impression that giving Lua its own thread, a different thread shouldn't be affected! Is this purely related to my own code in some way? Does LuaInterface have a some serious issues calling .NET functions (performance-wise)? What else could I use?
I didn’t try to compile LuaInterface against .NET 4. So far I used only the precompiled dlls. I know that you can speed up mixed image assemblies in .NET 4 by setting the to zero. According to MS: .NET Framework 4, a streamlined interop marshalling architecture provides a significant performance improvement for transitions from managed code to unmanaged code.
http://msdn.microsoft.com/en-us/library/ff361650.aspx
Keep us updated in case you find a trick which works for you. In Visual Studio 2010 you can actually build against .NET 2 so if I were you I would try to create a dummy app and compile it against multiple targets. It might help you to quantify the speed degradation when you are using .NET 4.
If you give us some code maybe I could play with it a bit and figure out what is wrong. I am really interested in LuaInterface and keen to figure out what is wrong.
Since I don't have a code sample I am just speculating on this; but it is possible that the issue is related to your UI not being thread safe. It is pretty common to have locking issues for example with Windows Forms Controls.
How to: Make Thread-Safe Calls to Windows Forms Controls
http://msdn.microsoft.com/en-us/library/ms171728(v=vs.80).aspx