As the title says, I'm experiencing very poor performance of the printf call in our code. It's used pretty extensivly for debugging purposes and hasn't caused an issue for the most part, but when I brought our code up on my new laptop (17" Macbook Pro 2011) under Windows 7 Professional 64 bit it slows down everything. I profiled the app with VerySleepy and sure enough it is the printf call that is causing the slow down, but I cannot for the life of me figure out why.
My original thought was that I was running a 32 bit app under a 64 bit os, but I'm not the only one in the office running Windows 7 64 bit (not sure the exact version of the others)
Any insight would be greatly appreciated.
EDIT: forgot to mention I'm using Visual Studio 2008 Professional
Make sure you got the latest and greatest graphics processor drivers on your box. If your printfs go to screen then bad drivers will kill performance.
Related
I have a WinForms application that is running fine under 32 bits, and is terribly slow under 64 bits (both Debug or Release builds). The environmant is .NET Framework 4.0, Windows 10. Occurs with different versions of Visual Studio.
Terribly slow means 1 second for 32 bits, 10 minutes for 64.
I have the feeling that the slowness occurs during the filling of a DataGridView, But I can't be definite.
I have tried using the Profiler, but all the time is spent in [External Code], which is completely opaque.
Have you already met a similar problem ? How can I investigate ?
I've been trying to research why certain compatibility features differ based on operating system so I can program a patch. I'm using the compatibility settings in the registry for Windows 95 to run a game (that of which the game was produced on) in each system. In Windows XP, the game runs perfectly. None of the scenes lag, and the sound works just as well as the scenes. I'm unsure of how it runs in Windows Vista, but in Windows 7 & 8 the compatibility feature breaks the game. I used a VM to run XP, but that doesn't effect the game's playability; real XP users have tested it. Whenever I play the game using the Win95 setting for compatibility in 7 & 8, everything lags. The music doesn't slow down during gameplay, but the graphics do. During cutscenes, they literally break. Everything pixelates, white noise and static increases volume, and the video lags every two seconds.
I therein tested it in Ubuntu Linux via WINE, and it runs better than it does in XP. I just had to use the alsa sound driver. What changed? If so, is it programmatically fixable? I'm using an amalgamation of C++, Batch and Java.
If it is necessary, the video game is entitled "The Neverhood."
Thanks.
The compatibility feature available in the shell is just scratching the surface of the "Application Compatibility" subject in Windows.
There is a tool called "Microsoft Application Compatibility Toolkit (ACT)" (that exist since Windows XP exist I believe) that has much more to offer, so maybe that can help.
For example here are some compatibility settings for Graphics Control Issues
I currently play "The Neverhood" on Win7 x64 without any visual problem, you are right when I played on Win7 for first time (4 years ago) was a headache and a little tricky to do the correct compatibility flags for each win version but finally I wrote this reg code for Win7 and worked for me while 4 years, sure it will work for you too:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Folder\\nhc.exe"="# WIN95 256COLOR 640X480 DISABLEDWM"
Where "C:\\Folder\\nhc.exe" of course is the path to your Neverhood. (Notice the double backslashes)
that flags means: Change Display color to 256 colors, change display resolution to 640x480, disable Themes service (DWM Service).
I hope this help you.
This may not answer the question directly, but if you want to improve performance of The Neverhood, change the compatibility to run in Windows 95 - then switch all other options ON, except the bottom three. This helps to make the game as fast and smooth as possible.
I have just recently installed Windows 8, and I tried to compile and build a simple c++ game project in VS 2010, but when I did, it was running at 5 fps. On windows 7, it runs at a solid 60 fps. Nothing has been changed in the code, but there is just horrible slow down.
I have updated my video drivers, but there is still horrible lag. I thought the problem was to do with compatibility issues with windows 8 and OpenGL, but I can't find anything to confirm this. I was wondering if anyone else has had this problem, and if you have solved it.
I would recommend you test your graphics card / drivers first. All sorts of driver issues could arise when you upgrade operating systems. One of the best tests would be to download Cinebench and see how it performs. Cinebench will evaluate your OpenGL performance. If you get poor results, then you know it's a hardware / driver issue and not an issue with your application.
If the Cinebench results are good, then you can move on to the recommendations made by #Robert Rouhani (comments).
http://www.maxon.net/products/cinebench/overview.html
What sort of video card do you have in the Win8 machine?
If it's a laptop you might be battling against nVidia Optimus (or an equivalent technology?). Basically programs have to tell the OS in advance that they want to use the video card or they get defaulted to using the low power GPU embedded in the CPU (note: over-simplification).
If this is the case, there's some options in the nVidia control panel to let you create a profile telling the OS to run your app with the discrete GPU, rather than the embedded one.
When debugging my Win32 Applications windows and dialogs sometimes (rarely) do not appear in the chosen Windows scheme, but rather reduced or broken:
The Window captions are all black (instead of blue or silver) and without any shadow. The Buttons doe not have any Button shape ("Abbrechen" in the screen shot). The black bar at the lower half is a windows progress bar. It doesn't show any progress when this happens.
The screen shot (details in the center greyed out) was taken from a 64-Bit application debugged under Visual Studio 2010 on XP SP3 x64 and a 10 GB machine. The was plenty of RAM (some GB) spare.
Does anyone have a clue for the reason? I never do non-client area drawing or something.
EDIT: The symptom only occurs when the Visual Studio Debugger has been attached to the program. But even when the application has been detached from the debugger the problem remains. It does not occur when starting the program without debugging.
There are at least two possibilities.
You use some other "theme engine" than the XP native, for example Clearlooks, etc. These engines may not always comply with all thing debuggers want, they may leave their message pump unpumped on some implicitly assumed (in debugger) point, and then the drawing just stalls. Same thing often happens when using some virtual desktop manager on windows, windows window manager is simply too hardwired..
Even 32bit programs in 32bit windows may run out of handles, this often results in windows starting being rendered with "Fixedsys" font. Your application shows symptoms only for Theme handled portions, which kind of indicates the possibility nr.1 again.
Try inspecting relevant windows with WinSpy and Process Explorer, unreasonable amounts of allocated resources may hint on what kind starvation is going on.
Have you installed SP1 for Visual Studio 2010? I haven't had this problem yet, but know that SP1 fixed a lot of problems with VS2010.
The other thing I do know is that WinXP x64 (which is still sp2 and not 3 btw) doesn't always play nice. It's not as well supported as the x86 version. Win Vista and 7 x64 allows for much smoother operation. (I have had some bad experiences with XP x64 myself)
We encounter this kind of trouble. In fact it was due to our antivurus (not sure but I think it was McAfee Viruscan at the moment).
I read about such symptoms (a while ago) so i googled it again and found the forum.
There seems to be an issue with some NVIDIA-drivers on WinXP-64. Also some people could get rid of the problem by reducing hardware-accelaration.
You might read the following forum (5 pages) yourself and decide if it applies to your situation.
http://forums.nvidia.com/index.php?showtopic=67608
To enforce visual styles in your application make sure to call it before you run your window, like this:
static void Main()
{
Application.EnableVisualStyles();
Application.Run(new Form1());
}
I've had the same problem happened before, particularly when using 3rd party components that use their own styling methods like Infragistics or ComponentOne
We get an app that was working fine until update Windows from Vista Home Basic to 7 Home Premium. We use mscomm32.ocx to control serial port, but it seems it's not supported for 64 bits OS.
Each time we try to read the port: Thisform.msCommControl.Input We got the following:
OLE IDispath exception code 0 from MSComm: Error reading comm devide
We've made a lot of unsuccessful tests. Does any one know how to fix this problem?
The solution is to use an updated control that is contantly under development so newer Windows are also supported. ADONTEC's SuperCom ActiveX is a MSComm compatible ActiveX that developers use for many years in order to replace the MSComm. It is compatible with 32 and 64 bit of Windows 2000/XP/7/8 and Windows 10. You are almost done in few minutes. In many cases the application runs not only faster but is by far more stable and it also offers by far more functionality. See more info here.
that MSCOMM32.OCX will not work with Windows 7 64 bit machines. However, strange as it may seem I have a VB6 program controlling equipment from a virtual comm port (USB ~ serial converter)
It works fine on windows 8.64 bit machine.
The only thing is that the converter driver had to be modified to run on 64 bit.
If you are using a real com port that doesn't matter.
Try it on a 64 bit machine with Windows 8