We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. Image for the cookie policy date
close icon

Memory problem

Hello, I''m using the version 3.2.1.0 of ExcelRW and I have a big memory problem. ExcelRW is using a huge amount of memory and the worst is that this memory is never released. After running 4 or 5 times the piece of code bellow, my machine gets out of memory (I have 1GB). As you can see, the piece of code is not doing anything, just doing a Count of a Range... private void button1_Click(object sender, System.EventArgs e) { IWorkbook myWorkBook=ExcelUtils.CreateWorkbook(1); IWorksheet sheet = myWorkBook.Worksheets[0]; int rows = 10000; int cols = 50; for (int i = 1;i
17 Replies

AD Administrator Syncfusion Team July 13, 2005 07:33 PM UTC

Hi Remy, Sorry for the delay in getting back to you. I tested your code using the Scitech memory profiler to test for memory leaks. Here are my observations 1) I took a snapshot of the heap when the application was started and before any ExcelRW objects were created. 2) I again ran your code and took another heap snapshot and compared it with the prevous snapshot. 3) Again, I ran the code and took another snapshot. When snapshot 2 and 3 were compared, I could not notice any new ExcelRW object instances created. This indicates the absence of Memory leak. However, I could see that the memory used was very high and we are seriously investigating into this issue. We have already started work on optimzing memory usage and hope to have huge improvements in the next couple of weeks. Thank you for your patience. Best regards, Stephen. >Hello, > >I''m using the version 3.2.1.0 of ExcelRW and I have a big memory problem. >ExcelRW is using a huge amount of memory and the worst is that this memory is never released. >After running 4 or 5 times the piece of code bellow, my machine gets out of memory (I have 1GB). As you can see, the piece of code is not doing anything, just doing a Count of a Range... > >private void button1_Click(object sender, System.EventArgs e) >{ >IWorkbook myWorkBook=ExcelUtils.CreateWorkbook(1); >IWorksheet sheet = myWorkBook.Worksheets[0]; >int rows = 10000; >int cols = 50; > >for (int i = 1;i{ > for(int j=1; j { > int test = sheet[i, j].Count; > } >} >MessageBox.Show("Finished"); >} > >The problem exists for debug and release versions. > >Is there a fix for this? >I would really appreciate a soon answer. > >Thank you. > Rémy.


GM George Mihaescu July 22, 2005 01:12 AM UTC

Remy is in fact raising 2 problems (I had the same issues): 1) high memory usage during exports of large data sets 2) the memory is not released 1) is something Syncfusion will have to work on, and that''s gonna be very tricky. In my case I am creating many sheets in the workbook, and I don''t see how Syncfusion can avoid storing the whole data set (for all sheets) in memory before being able to Save, when in theory there could be dependencies among the cells of the various sheets, etc. 2) I think I found where the leak is, and I also have a workaround for it. The problem is the storage of a reference in a static member of the ExcelUtils class, and therefore the refered object will live forever once Excelutils is used. The workaround: don''t use ExcelUtils. My tests show that if the workbook is created not in the way Syncfustion advertises in the KB and in the samples, i.e.: IWorkbook work_book = ExcelUtils.CreateWorkbook (1); ... work_book.Close (); but rather: ExcelEngine engine = new ExcelEngine (); IWorkbook work_book = engine.Excel.Workbooks.Add (); ... work_book.Close (); engine.Dispose (); the leak is gone. Regards, George >Hi Remy, > >Sorry for the delay in getting back to you. > >I tested your code using the Scitech memory profiler to test for memory leaks. Here are my observations > >1) I took a snapshot of the heap when the application was started and before any ExcelRW objects were created. > >2) I again ran your code and took another heap snapshot and compared it with the prevous snapshot. > >3) Again, I ran the code and took another snapshot. When snapshot 2 and 3 were compared, I could not notice any new ExcelRW object instances created. This indicates the absence of Memory leak. > >However, I could see that the memory used was very high and we are seriously investigating into this issue. We have already started work on optimzing memory usage and hope to have huge improvements in the next couple of weeks. Thank you for your patience. > >Best regards, > >Stephen. > >>Hello, >> >>I''m using the version 3.2.1.0 of ExcelRW and I have a big memory problem. >>ExcelRW is using a huge amount of memory and the worst is that this memory is never released. >>After running 4 or 5 times the piece of code bellow, my machine gets out of memory (I have 1GB). As you can see, the piece of code is not doing anything, just doing a Count of a Range... >> >>private void button1_Click(object sender, System.EventArgs e) >>{ >>IWorkbook myWorkBook=ExcelUtils.CreateWorkbook(1); >>IWorksheet sheet = myWorkBook.Worksheets[0]; >>int rows = 10000; >>int cols = 50; >> >>for (int i = 1;i>{ >> for(int j=1; j> { >> int test = sheet[i, j].Count; >> } >>} >>MessageBox.Show("Finished"); >>} >> >>The problem exists for debug and release versions. >> >>Is there a fix for this? >>I would really appreciate a soon answer. >> >>Thank you. >> Rémy.


AN Andrew August 4, 2005 08:01 PM UTC

Can someone from SyncFusion reply to this? >Remy is in fact raising 2 problems (I had the same issues): >1) high memory usage during exports of large data sets >2) the memory is not released > >1) is something Syncfusion will have to work on, >and that''s gonna be very tricky. In my case >I am creating many sheets in the workbook, >and I don''t see how Syncfusion can avoid storing the whole data set (for all sheets) in memory before being able to Save, when in theory there could be dependencies among the cells of the various sheets, etc. > >2) I think I found where the leak is, and I also >have a workaround for it. The problem is the >storage of a reference in a static member of >the ExcelUtils class, and therefore the refered object will live forever once Excelutils is used. >The workaround: don''t use ExcelUtils. >My tests show that if the workbook >is created not in the way Syncfustion advertises in the KB and in the samples, i.e.: > >IWorkbook work_book = ExcelUtils.CreateWorkbook (1); >... >work_book.Close (); > >but rather: > >ExcelEngine engine = new ExcelEngine (); >IWorkbook work_book = engine.Excel.Workbooks.Add (); >... >work_book.Close (); >engine.Dispose (); > >the leak is gone. > >Regards, >George > >>Hi Remy, >> >>Sorry for the delay in getting back to you. >> >>I tested your code using the Scitech memory profiler to test for memory leaks. Here are my observations >> >>1) I took a snapshot of the heap when the application was started and before any ExcelRW objects were created. >> >>2) I again ran your code and took another heap snapshot and compared it with the prevous snapshot. >> >>3) Again, I ran the code and took another snapshot. When snapshot 2 and 3 were compared, I could not notice any new ExcelRW object instances created. This indicates the absence of Memory leak. >> >>However, I could see that the memory used was very high and we are seriously investigating into this issue. We have already started work on optimzing memory usage and hope to have huge improvements in the next couple of weeks. Thank you for your patience. >> >>Best regards, >> >>Stephen. >> >>>Hello, >>> >>>I''m using the version 3.2.1.0 of ExcelRW and I have a big memory problem. >>>ExcelRW is using a huge amount of memory and the worst is that this memory is never released. >>>After running 4 or 5 times the piece of code bellow, my machine gets out of memory (I have 1GB). As you can see, the piece of code is not doing anything, just doing a Count of a Range... >>> >>>private void button1_Click(object sender, System.EventArgs e) >>>{ >>>IWorkbook myWorkBook=ExcelUtils.CreateWorkbook(1); >>>IWorksheet sheet = myWorkBook.Worksheets[0]; >>>int rows = 10000; >>>int cols = 50; >>> >>>for (int i = 1;i>>{ >>> for(int j=1; j>> { >>> int test = sheet[i, j].Count; >>> } >>>} >>>MessageBox.Show("Finished"); >>>} >>> >>>The problem exists for debug and release versions. >>> >>>Is there a fix for this? >>>I would really appreciate a soon answer. >>> >>>Thank you. >>> Rémy.


AD Administrator Syncfusion Team August 8, 2005 10:52 AM UTC

Hi Andrew, Sorry for the delay in getting back to you. 1) Yes, George are correct, Its is a bug in the ExcelUtils class. The ExcelUtils class was initially created as a wrapper class to simplify the API usage but it has been found based on feedback that the Inner API which used a two step instantiation procees is not as confusing as originally reported by beta testers since its similar to MS Excel, hence the ExcelUtils class will be marked as obsolete soon and all samples and documentation will be updated to use the second following style of coding that George has mentioned. You can find more code samples here http://www.syncfusion.com/support/EvaluationCenter/default.aspx?cNode=4 We are also currently reworking our code to make it more optimized in both in terms of performance and memory consumption and we have recently made some good progress. The Template spreadsheet opening speed and the file serialization speed have been greatly reduced. The current focus is on reducing the memory consumption when dealing with large spreadsheets which include storing strings in an optimized way and not creating style objects unless they are accessed etc which is expected to be done in about 3-4 weeks time. Thank you for your patience. Best regards, Stephen.


RH Rose Hoskins September 16, 2005 01:50 PM UTC

I''m jumping in late, but I just started working with SyncFusion Essential Studio v3.3.0.0 and I''m seeing the same kind of ExcelRW memory problems noted here (i.e., memory usage grows greatly during workbook generation, then does not seem to be released when I close the workbook and set the workbook and worksheet objects to null). I''m generating 12,000 row workbooks and seeing 500MB memory usage per run. I am exclusively using the IRange interface to populate the cells (either the Text or Value2 properties). I just wanted to check whether this should have been fixed in 3.3 since messages I''ve seen in the forums so far reference v3.2 or earlier. Other than the memory issues, I''m very pleased with the interface and the speed of workbook generation. Thanks, -Rose >Hi Andrew, > >Sorry for the delay in getting back to you. > >1) Yes, George are correct, Its is a bug in the ExcelUtils class. The ExcelUtils class was initially created as a wrapper class to simplify the API usage but it has been found based on feedback that the Inner API which used a two step instantiation procees is not as confusing as originally reported by beta testers since its similar to MS Excel, hence the ExcelUtils class will be marked as obsolete soon and all samples and documentation will be updated to use the second following style of coding that George has mentioned. You can find more code samples here > >http://www.syncfusion.com/support/EvaluationCenter/default.aspx?cNode=4 > >We are also currently reworking our code to make it more optimized in both in terms of performance and memory consumption and we have recently made some good progress. The Template spreadsheet opening speed and the file serialization speed have been greatly reduced. The current focus is on reducing the memory consumption when dealing with large spreadsheets which include storing strings in an optimized way and not creating style objects unless they are accessed etc which is expected to be done in about 3-4 weeks time. Thank you for your patience. > >Best regards, > >Stephen.


AD Administrator Syncfusion Team September 19, 2005 11:17 AM UTC

Hi Rose, Version 3.3 does have some improvement in memory usage over the previous version but it only optimized the process of reading large spreadsheets into memory. However, this optimization would not be of much help to you since you are creating a spreadsheet from scratch. 1) Currently we are still working on optimizing XlsIO for both using lesser memory when creating large spreadsheet. A quick test using the latest version shows that it takes about 300MB to generate a spreadsheet of size 12,000 rows and 40 columns, with the following code for(int i=1;i<12000;i++) { for(int j=1;j<40;j++) { mySheet.Range[i,j].Text = string.Format("row{0} col{1}", i, j); } } The same sample takes about 20% more momory in version 3.3. Please create a Direc-Trac insident so that I can provide you with the latest custom build assemblies for testing. 2) We are still actively working on reducing memory usage so there should be siginificant improvements to the performance and memory usage in the next 4 weeks time. 3) Regarding the memory leak, are you seeing the memory grow my 500MB each time you create the spreadsheet?, could you please run this code snippet and let me know if you see the problem or memory growing in each run InsertData.zip Thanks, Stephen.


RH Rose Hoskins September 19, 2005 08:50 PM UTC

Stephen, I will create the incident, but first I wanted to respond to your questions here. Memory usage for my application goes from a base of 60MB or so to 500MB for a workbook generation. Since this posting, I switched to using the ExcelEngine directly (rather than ExcelUtils) to create my workbook so that I can call Dispose() on the engine. After I did that plus add an explicit garbage collection call, the application does not retain the 500MB over subsequent generations. I''m still definitely interested in achieving less memory usage during a single generation, however. Interestingly, I ran the example you sent and memory usage for that application never really goes over 80MB. Note, I''m only using Windows Task Manager to watch memory consumption. If you''d like me to try something else, let me know. Thanks. I''ll create the DirectTrac incident as you requested as well. -Rose >Hi Rose, > >Version 3.3 does have some improvement in memory usage over the previous version but it only optimized the process of reading large spreadsheets into memory. However, this optimization would not be of much help to you since you are creating a spreadsheet from scratch. > >1) Currently we are still working on optimizing XlsIO for both using lesser memory when creating large spreadsheet. A quick test using the latest version shows that it takes about 300MB to generate a spreadsheet of size 12,000 rows and 40 columns, with the following code > > for(int i=1;i<12000;i++) > { > for(int j=1;j<40;j++) > { > mySheet.Range[i,j].Text = string.Format("row{0} col{1}", i, j); > } > } > >The same sample takes about 20% more momory in version 3.3. > >Please create a Direc-Trac insident so that I can provide you with the latest custom build assemblies for testing. > >2) We are still actively working on reducing memory usage so there should be siginificant improvements to the performance and memory usage in the next 4 weeks time. > >3) Regarding the memory leak, are you seeing the memory grow my 500MB each time you create the spreadsheet?, could you please run this code snippet and let me know if you see the problem or memory growing in each run > >InsertData.zip > >Thanks, > >Stephen. >


KA Kev, AT October 20, 2005 12:55 PM UTC

HI, We''ve bought your Xlsio component a few weeks ago, and we have the same problem. We''ll soon need to use this component massively, and we would like to know if this problem will be fix quickly ? It''s really important for us, and if the results are not better, wi''ll have to find out an other component. Thanks a lot, Kev >Hi Rose, > >Version 3.3 does have some improvement in memory usage over the previous version but it only optimized the process of reading large spreadsheets into memory. However, this optimization would not be of much help to you since you are creating a spreadsheet from scratch. > >1) Currently we are still working on optimizing XlsIO for both using lesser memory when creating large spreadsheet. A quick test using the latest version shows that it takes about 300MB to generate a spreadsheet of size 12,000 rows and 40 columns, with the following code > > for(int i=1;i<12000;i++) > { > for(int j=1;j<40;j++) > { > mySheet.Range[i,j].Text = string.Format("row{0} col{1}", i, j); > } > } > >The same sample takes about 20% more momory in version 3.3. > >Please create a Direc-Trac insident so that I can provide you with the latest custom build assemblies for testing. > >2) We are still actively working on reducing memory usage so there should be siginificant improvements to the performance and memory usage in the next 4 weeks time. > >3) Regarding the memory leak, are you seeing the memory grow my 500MB each time you create the spreadsheet?, could you please run this code snippet and let me know if you see the problem or memory growing in each run > >InsertData.zip > >Thanks, > >Stephen. >


AD Administrator Syncfusion Team November 21, 2005 05:17 AM UTC

Hi Kev, Sorry for the delay in gettting back to you. Please try using this latest internal version which has much better performance than version 3.3. (Please note that you need to have version 3.3 installed in order to use this assembly) 1) Download this latest assembly from here Syncfusion.XlsIO.Base.zip 2) Place the assembly in C:\Program Files\Syncfusion\Essential Studio\Assemblies\1.1 3) Drag the assembly from this folder C:\Program Files\Syncfusion\Essential Studio\Assemblies\1.1 on to the GAC (C:\WINDOWS\assembly) 4) Now remove reference to Syncfusion.ExcelRW.Base and Syncfusion.ExcelRW.Windows from your application and reference this assembly. 5) Now change namespace reference to using Syncfusion.XlsIO; 6) Recompile application. Please let me know if you have any questions. Thanks, Stephen.


VD Vaishali Dias March 29, 2006 03:30 AM UTC

Hello Stephen, With reference to this thread of Memory problem , even I am facing some critical issues in my application. We have been using XLIO for almost 3 months for creating Excel output files. Recently the Application is extensively used for creating Output Files which has lots of data in in and it started giving errors like Exception of type System.OutOfMemoryException was thrown I noticed that the output file generated using XLIO has some X Size.If we open it again using Microsoft Excel and just click on Save and close it the size reduces to X /2. The DLLs that we are referencing in our Application are as mentioned below : 1. SyncFusion.XlsIO.Base Version 4.101.0.50 2. SyncFusion.XlsIO.Windows Version 4.101.0.50 Please get back to me ASAP on this else hard to say but We have to shift to some other component. your Help would be highly appreciated in this matter. Thanks, Vaishali


AD Administrator Syncfusion Team April 3, 2006 04:51 PM UTC

Hi Vaishali, Sorry for the delay in getting back to you. 1) Would it be possible to let me know the size of the report that you are trying to create..ie, the number of rows, columns and worksheets. 2) Also, what type of data is present in the cells like numbers, string etc 3)If possible please provide a sample where we can reproduce the problem. We will try our best to resolve this issue as soon as possible. Best regards, Stephen. >Hello Stephen, > >With reference to this thread of Memory problem , even I am facing some critical issues in my application. >We have been using XLIO for almost 3 months for creating Excel output files. >Recently the Application is extensively used for creating Output Files which has lots of data in in and it started giving errors like > >Exception of type System.OutOfMemoryException was thrown > >I noticed that the output file generated using XLIO has some X Size.If we open it again using Microsoft Excel and just click on Save and close it the size reduces to X /2. > >The DLLs that we are referencing in our Application are as mentioned below : >1. SyncFusion.XlsIO.Base Version 4.101.0.50 >2. SyncFusion.XlsIO.Windows Version 4.101.0.50 > >Please get back to me ASAP on this else hard to say but We have to shift to some other component. > >your Help would be highly appreciated in this matter. > >Thanks, >Vaishali > > > >


JL Jeff Lu April 4, 2006 05:30 PM UTC

We are using 4.1.0.62, but even before we upgraded from version 3, we have had problems with memory and long open/save times, even for relatively small spreadsheets. I have attached an example. The 2nd and 3rd spreadsheet only have 10 columns, but XlsIO insists that they have 255 columns. This increases the memory usage by a factor of 25. Both Excel and another xls reader dimension the sheet correctly. I think this would be okay except there is no way for me to reset this number (Even Excel won''t listen). I have seen other spreadsheets which are not that large but which the number of rows is taken to be >65K. It would be great if we were able to truncate the number of columns and number or rows.

TemplateAffiliations.zip


AD Administrator Syncfusion Team April 6, 2006 01:04 AM UTC

Hi Jeff, Thanks for providing the template document, I was able to see the problem and have filed Bug ID# 1828 with the development team. We will try to fix it as soon as possible. Best regards, Stephen.


OS Olajide Sanu May 10, 2006 01:53 PM UTC

Hi I too am having memory problems using v 3.2.1.0. I note the work around earlier in this thread using the following: ExcelEngine engine = new ExcelEngine (); IWorkbook work_book = engine.Excel.Workbooks.Add (); However I need to use pre created templates for my application. I currently use: ExcelUtils.CreateWorkBookUsingTemplate(string path) Is there an equivalent workaround for this situatation Thankls in advance Jide


IP Ivan Pelly May 11, 2006 10:12 PM UTC

Hi Syncfusion: Using version 4.102.0.50, the attached code consumes 330MB just reading a blank worksheet. It seems that internally the XLSIO code must be creating and holding onto an object for each range accessed. This behavior make the component unsuitable for our purposes. Since the problem has been ongoing for many months, how about (given that my assumption above is correct) giving the developer the option of disabling the internal creation of this "cache" of range objects. Granted, the code might run slower, but that''d be preferrable to the current arrangement. Thanks.

Test31.zip


AD Administrator Syncfusion Team May 15, 2006 03:15 PM UTC

Hi Ivan, Sorry for the delay in getting back to you. 1) Yes, I was able to see the problem in your sample. The currently implementation creates a Range object whenever a range is accessed so there is no way to disable that currently. However we are currently reworking this and should have a good solution to avoid this memory overload in a months time (or sooner if possible). 2) However you can use the UsedRange in some cases to avoid creating range objects for all cells in a worksheet 25446MemoryProblem.zip 3) Also, could you please confirm if your requirement is to read workbook data or do you need to also write them? Please let me know if you have any questions. Thanks, Stephen. >Hi Syncfusion: > >Using version 4.102.0.50, the attached code consumes 330MB just reading a blank worksheet. It seems that internally the XLSIO code must be creating and holding onto an object for each range accessed. This behavior make the component unsuitable for our purposes. Since the problem has been ongoing for many months, how about (given that my assumption above is correct) giving the developer the option of disabling the internal creation of this "cache" of range objects. Granted, the code might run slower, but that''d be preferrable to the current arrangement. Thanks.

Test31.zip


AD Administrator Syncfusion Team May 15, 2006 03:18 PM UTC

Hi Jide, You would need to use the open method ExcelEngine engine = new ExcelEngine (); IWorkbook work_book = engine.Excel.Workbooks.Open("Template.xls"); Please let me know if you have any questions. Best regards, Stephen. >Hi > >I too am having memory problems using v 3.2.1.0. >I note the work around earlier in this thread using the following: > >ExcelEngine engine = new ExcelEngine (); >IWorkbook work_book = engine.Excel.Workbooks.Add (); > > >However I need to use pre created templates for my application. > >I currently use: > >ExcelUtils.CreateWorkBookUsingTemplate(string path) > >Is there an equivalent workaround for this situatation > >Thankls in advance > >Jide

Loader.
Live Chat Icon For mobile
Up arrow icon