So i have a setup where two imacs, imac_1 and imac_2, are connected through firewire. imac_1 sends some debugging information to imac_2 and on imac_2 i have a program in c++ that captures debugging information.(see illustration below)
Now the problem is that if i write the debugging info to the GUI (created using QT) directly its very slow, by slow i mean that the GUI takes time to load the data. So what i did was to write the debugging info to a buffer and then dump that buffer into the GUI but that was also slow because the GUI takes time to load the data.
I was thinking of writing the debugging info to a file and then loading that into the gui. So i would load the first 10,000 lines into the gui and then when the user scrolls down i would load next 10,000 lines.
imac_1(transmitter) --->FireWire (medium) --> imac_2 (receiver)
any ideas or suggestions????
i am using:
Mac OS X,
XCode,
imac
It sounds like your problem has nothing to do with the two computers communicating, but may instead be your GUI application.
I would suggest you try the file approach you mention, if only to isolate the network component from the discussion. Then work on making your GUI faster.
If you are adding the lines of text one at a time, that might account for some of the slowness, but 10,000 lines isn't really that many.
Other approaches might include turning off redrawing or something similar while you are loading in the text file.
Related
I'll copy here part of my previous question to describe the problem:
I wrote an application in C++ that has two parts - the frontend and
the backend. These two communicate using IPC layer provided by
wxWidgets. In the backend I use some legacy functions for image data
manipulation. One of these functions hangs or falls into some infinite
loop sometimes (I can observe that 0% of the process resources are
used by the process after some point), but this happens only if I ran
the backend as a subprocess of the frontend. Otherwise (when I run it
manually) it works just fine.
It turns out that printing too many lines with std::cout was causing that, but I'd like to understand why. Could it be that wxWidgets utilizes some buffer for storing application output and printing was simply overflowing it? Or this is rather native issue of Windows? Or maybe it could be related to std::cout implementation? I'm pretty sure I'm not able to reproduce this with printf It seems that I was wrong - printf also seems to trigger that issue
The stdout buffer is of a finite size. Something must be reading what you are writing into the buffer, whether this is a file, a console window or another process. If you write faster than the reader is able to cope with then the buffer will eventually fill up and block any further writes until the reader has read some data.
I have an application (didn't write it) that is producing APPCRASH dumps in C:\Windows\SysWOW64. The application while dumping is crippled, but operating at bare minimum capacity to not lose data. The issue is that these dumps are so large that the system is spending most of it's time writing these and the application is falling far behind in processing and will start losing data soon.
The plan is to either entirely disable it, or mount it to a RAM drive and purge them as soon as they hit the RAM drive.
Now I've looked into using this key:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb787181%28v=vs.85%29.aspx
But all it does is generate a second dump now instead of redirect the original.
The dump is named:
dump-2013_03_31-15_23_55_772.dmp
This is generally the realm of developers on Windows (with stuff like C/C++) so I'd like to hit them up, don't think ServerFault could get me any answers on this.
Additionally: It's not cycling dump files (they'll fill the 20GBs left on the hard drive), so I'm not sure if this is Windows behavior or custom code in the app (if it is... ick!).
To write a DumpFile, an app has to call the function "MiniDumpWriteDump" so this is not a behavior of the system or something you can control, it is application driven. If it dumps on crashes, it uses "SetUnhandledExceptionFilter" to set its own handling routine, before(!) the OS takes over. Unfortunately I didn't found a way to overwrite this handler from an other process, so the only hope left is, that there is a register entry for the app switching the behavior or change the path (as my applications have it for exactly the reason you describe).
I have written a code in C++ to open a file in its default application like .doc in MS-Word now I want to calculate time to open a file into its application.
For that I need to know percentage of file loaded into that application. But from last 7 days I couldn't find any suitable solution. So can any one help me in solving this problem?
If i am using windows then can windows task manager help me to do this?
What you're trying to do is not only impossible, it doesn't even make sense.
When you play an MP3 in WMP, it doesn't load the whole file into memory. Instead, it maps a little bit of the file at a time into memory so it can decode the MP3 on the fly as it's playing. (I suppose if you play the song all the way through, without stopping or skipping or fast forwarding or rewinding, it will eventually read every byte of the file, probably finishing a few seconds before the song is over, but I doubt that's what you're looking for.)
Likewise, Word doesn't read any entire .doc file into memory (unless it's very small). That's how it's able to edit gigantic files without using huge amounts of memory. (Again, if you page through the whole file, it will probably eventually read every byte—for that matter, it may eventually copy enough of the file into an autosave backup file that it no longer needs to look at the original—but again, I doubt that's what you're looking for.)
If you only care about certain specific applications, and those applications have a COM Automation interface (as both WMP and Word do), they may have methods or events that will tell you when they're done "loading" a file (meaning they've read enough of it to start playing/displaying/etc.), or when they've "finished" with a file (meaning moved on to the next track, or whatever), but there's no generic answer to that; different applications will have different Automation interfaces. (And, as a side note, you really don't want to do COM Automation from C++ unless you really have to; it's much easier from jscript, vbscript, or your favorite .NET language…)
If the third party process does not signal that it has loaded something, e.g., through some output stream, one way will be to view the file handles being opened and closed by the processes. I presume this will be similar to how "task managers" like Process Explorer are able to view file handles of processes. However, if the process does not close the file handle once it is done "loading", then, you will not get an accurate time. Furthermore, you won't be able to get a "live" percentage of how much data has been loaded.
I have a simple Qt program running on Windows XP - its just a data logging program. It reads any data sent to it on the serial port and then it pushes this to the GUI and logs it to a text file.
The thing is, if I run the program for an hour (roughly, sometimes more) it will hang up on me. The GUI locks out and the program stops logging. On the CPU monitor on the performance tab of my task manager, one of my cores always goes straight to 100% when this crash happens and stays there until I close the hung application.
I have literally no experience in diagnosing problems like this - has anyone got any tips on where to start?
Run the application until it freezes and then attach a debugger. Look through the threads and check where each one of them is. This should give some clues on what's going on. For threads that are stopped within framework code an investigation of the call stack should show if your code is involved.
Make sure that you do this on a debug build with all symbols included to get readable results.
I have written a small program using Borland's C++ builder, and along the way, everything seemed fine. My program has a map window and a table window, and when a user presses a button, a long process is started that reads in all the map and table information and then displays that. Every time i ran it through the debugger, I had no issues. Then today, I decided to test it without running it through the debugger. To my horror, The program reads in the map information and then displays it on the paintbox canvas without a problem, but when it loads the information for the grid, the map gets erased!!! It appears to happen during the load phase for the table. this takes about 4 seconds, and during which time, the window tells me that it isnt responding. This is when the map gets erased. Anyone have any ideas on why this is happening? Its driving me nuts, and I dont really understand whats going on under the hood here.
UPDATE:
I have fixed the problem to some degree. I was poking around and found this: Avoiding "(Not Responding)" label in windows while processing lots of data in one lump
I added the code to run once in the middle of the data read in for the table. this fixed my problems. however, I was wondering if anyone knows why this is the case? why does my program going unresponsive cause my canvases to be erased?
Marcus Junglas wrote a detailed explanation of the problem, which affects both Delphi and C++Builder.
When programming an event handler in
Delphi (like the OnClick event of a
TButton), there comes the time when
your application needs to be busy for
a while, e.g. the code needs to write
a big file or compress some data.
If you do that you'll notice that your
application seems to be locked. Your
form cannot be moved anymore and the
buttons are showing no sign of life.
It seems to be crashed.
The reason is that a Delpi application
is single threaded. The code you are
writing represents just a bunch of
procedures which are called by
Delphi's main thread whenever an event
occured. The rest of the time the main
thread is handling system messages and
other things like form and component
handling functions.
So, if you don't finish your event
handling by doing some lengthy work,
you will prevent the application to
handle those messages.
You can reduce the problem by calling Application->ProcessMessages(), while loading your map data, however I recomend using a separate thread to load the data.
I have never used C++ Builder, but i used Delphi. I think the libraries are the same.
Does that component you use store the image data? It may only draw to the screen. Try covering the window of your app with another window. If it erases it, you have to use a component which stores the image.
See this, it is for Delphi, but it may help. There should be a Image component in C++ Builder. Try using that instead of PaintBox.
You can solve the unresponsivenes problem by running the time consuming task in a separate thread or calling some function that processes the window's messages.