Hi there!
I have recently created a program that is very intensive spreadsheet intensive.
I have done this through a VB Windows Form using: Imports Excel = Microsoft.Office.Interop.excel.
basically what this program does is that it examines numerical values in 1333 rows, for each 125 colums inside of one worksheet, then when this is done, skips over to the next worksheet and repeats the same process for 1333 rows and 125 colums etc, for a total of nine worksheets. While its examing the rows, when it is finished it places the result on an entirely different workbook (which has already been opened at the beginning of the program's execution)
Now here's this process takes forever, about 50 minutes to complete 9 sheets. In the near future, I'll need to examine 180 all together.
On top of this, -in the code's operations when completed after a 50 minute session, needs to be rerun- with variables changing to re-examine the same data, but with a widerscope of rowvalues than the previous run. And this is also done 9 times.
So, I thought, is there a faster way to get my program to do some of these operations in parallel, using the TPL that I've recently searched about.
For instance. Could I break down my code into classes like this psuedo-code:
Parallel.invoke(Sub("Firstrun")Sub("Secondrun")Sub("Thirdrun").....Sub("NthRun")
In order to accomplish a faster runtime?
The reason this also is confounding my brain, is when I open the spreadsheet at the VB Form level by exectution, can the operations performed on the sheet be done in parallel?
I don't see why not....But....Never tried to break my code down into classes, then execute them all at the same time, instead of running them individually.
The other reason I want to use the TPL approach is because from what I've read, it automatically adjusts the thread propogation and cores usage to that of your resident chip.
Can Parallel.invoke be used like this?
Or is there a better parallel approach? So I guess the final point of clarifcation is that I already have complete working code- cutting down on runtime is the ultimate goal.
Thanks for reading!
Michael.
I have recently created a program that is very intensive spreadsheet intensive.
I have done this through a VB Windows Form using: Imports Excel = Microsoft.Office.Interop.excel.
basically what this program does is that it examines numerical values in 1333 rows, for each 125 colums inside of one worksheet, then when this is done, skips over to the next worksheet and repeats the same process for 1333 rows and 125 colums etc, for a total of nine worksheets. While its examing the rows, when it is finished it places the result on an entirely different workbook (which has already been opened at the beginning of the program's execution)
Now here's this process takes forever, about 50 minutes to complete 9 sheets. In the near future, I'll need to examine 180 all together.
On top of this, -in the code's operations when completed after a 50 minute session, needs to be rerun- with variables changing to re-examine the same data, but with a widerscope of rowvalues than the previous run. And this is also done 9 times.
So, I thought, is there a faster way to get my program to do some of these operations in parallel, using the TPL that I've recently searched about.
For instance. Could I break down my code into classes like this psuedo-code:
Parallel.invoke(Sub("Firstrun")Sub("Secondrun")Sub("Thirdrun").....Sub("NthRun")
In order to accomplish a faster runtime?
The reason this also is confounding my brain, is when I open the spreadsheet at the VB Form level by exectution, can the operations performed on the sheet be done in parallel?
I don't see why not....But....Never tried to break my code down into classes, then execute them all at the same time, instead of running them individually.
The other reason I want to use the TPL approach is because from what I've read, it automatically adjusts the thread propogation and cores usage to that of your resident chip.
Can Parallel.invoke be used like this?
Or is there a better parallel approach? So I guess the final point of clarifcation is that I already have complete working code- cutting down on runtime is the ultimate goal.
Thanks for reading!
Michael.