Question Using threads to improve GUI performance

jlhsfs

New member
Joined
Sep 30, 2015
Messages
2
Programming Experience
10+
I have developed a GUI in c# .NET 3.5 using VS2008. One function of the GUI is to launch an executable written in Fortran using the Process class in System.Diagnostics. The code to do this is:


ProcessStartInfo si = new ProcessStartInfo(path-to-executable, args);
Process runProc = null;
runProc = Process.Start(si);


The only way to communicate between the executable and GUI is via files that are spawned by one or the other during execution. The executable solves a problem by iteration and writes a set of files after each iteration. The GUI reads the data in the files and displays a graphical representation of the data, which updates with each iteration.


I'm dissatisfied with the execution time of the GUI. On a typical case, the executable running in standalone mode required 23 seconds to complete, but 38 seconds when running under the GUI. I had hoped that the OS would assign the runExec process to a separate thread that would not be interrupted by the operation of the GUI thread. Since that appears not to be the case, I manually imposed such an assignment by encapsulating the above code in a function:


private void runExec()
{
ProcessStartInfo si = new ProcessStartInfo(path-to-executable, args);
Process runProc = null;
runProc = Process.Start(si);
}


and inserted the following where the process was originally invoked:


Thread t = new Thread(runExec);
t.Start();


This had no effect on the execution time in the GUI, so my questions to the forum are:


1. Is my expectation that most or all of the time penalty running under the GUI can be eliminated by threading unrealistic?
2. If not, am I implementing and using the new thread wrong?
3. Is there a better way to accomplish this (Tasks are not supported in .NET 3.5)?

Thanks to all. Any new insights are appreciated.
 
Processes contain threads, not the other way around. It's not possible for the new process to run on a thread belonging to your current process. Is it possible that your app is locking files that the other app must then wait for?
 
Great answer

Processes contain threads, not the other way around. It's not possible for the new process to run on a thread belonging to your current process. Is it possible that your app is locking files that the other app must then wait for?
I suspect you have nailed it. To minimize the contention for shared files, I think I will simply copy the file spawned by the executable and read from the copied file in the GUI. Thanks for the suggestion.
 

Latest posts

Back
Top Bottom