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.
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.
