My goal to copy the excel data to SQL table by processing each cell (Need to have exactly same as excel data in SQL table).
Currently we are using Aspose Cells version 8.2.0.0. During performance testing memory leaks are reported.
So we are thinking to use 17.2.0.0 version Aspose Cells as it also supports explicit Dispose API on WorkBook Object.
To analyze memory leak issue, I explicitly called GC.Collect() after the processing is done by using both version Dlls. Live object count and memory is more or less same in both versions even after GC.Collect(). Please see the memory analysis as in attached.
My questions are : Why still memory leak is there in new version of Aspose Cells as well?
Do we need to take any actions not to have leak in either of the versions?
Please guide me.
We have been improving and doing enhancements since many versions so we think, newest version should perform better.
We recommend you to perform the testing on most recent version which is at the moment 18.2.
Please note, here 18 means 2018 and 2 means February. Hence, the next official version will be 18.3 where 3 would mean March.
Note: I am working as Developer Evangelist at Aspose
Related
This isn't really a programming question perse, but at work we have been forced to upgrade from Excel 2007 to Excel 2016 which has caused some productivity issues with respect to opening multiple workbooks at once.
The problem is that our entire file system has a bunch of linked formulas and iterative calculations where it is necessary to have multiple workbooks open at once (around 60+). Previously with Excel 2007 we were able to do this easily with relatively low power computers (4 gigs of ram, with a mediocre hyperthreaded i3 processor) but with the new change to Excel 2016 we keep getting an error stating to "upgrade to 64-bit Excel" or "install more physical memory". The error message can be seen here. We have already upgraded to 64-bit Excel, and on top of that, I tried using other co workers computers with 8 and 16 gigs of ram which resulted in little to no difference. Does this imply that perhaps Excel 2016 is not well optimized for having this many workbooks open at the same time? Are there solutions or workarounds this problem? I find it hard to believe that 16 gigs of ram is still insufficient when 2007 was able to go through this process easily, though perhaps the change from MDI to SDI means less efficiency?
As an aside, yes, I do indeed wish we were not using Excel for such a computationally expensive process in which Excel may not have been designed for tasks like these, but to move everything to something like SAS would take a lot of time I'd imagine and ultimately, I don't make the decisions :(
Thanks for any help.
I am looking after an app built with Node JS that's producing some interesting issues. It was originally running on Node JS v0.3.0 and I've since upgraded to v0.10.12. We're using Node JS to render charts on the server and we've noticed the memory usage keeps climbing chart after chart.
Q1: I've been monitoring the RES column in top for the Node JS process, is this correct or should I be monitoring something else?
I've been setting variables to null to try and reallocate memory back to the system resources (I read this somewhere as a solution) and it makes only a slight difference.
I've pushed the app all the way to 1.5gb and it then ceases to function and the process doesn't appear to die. No error messages which I found odd.
Q2: Is there anything else I can do?
Thanks
Steve
That is a massive jump in versions. You may want to share what code changes you may have made to get it working on latest stable. The api is not the same as back in v0.3, so that may be part of the problem.
If not then the issue you see it more likely from heap fragmentation than from an actual leak. In later v8 versions garbage collection is more liberal with cleanup to improve performance. (see http://code.google.com/p/chromium/issues/detail?id=112386 for some discussion on this)
You may try running the application with --max_old_space_size=32 which will limit the amount of memory v8 can use to around 32MB. Note the docs say "max size of the old generation", so it won't be exactly 32MB. Just around it, for lack of a better technical explanation.
Also you can track the amount of external memory usage with --trace_external_memory. This will allow you to know if external memory (i.e. Buffers) are being retained in your application.
You're note on the application hanging around 1.5GB would tell me you're probably on a 64-bit system. You only mentioned it ceases to function, but didn't note if the CPU is spinning during that time. Also since I don't have example code I'm not sure of what might be causing this to happen.
I'd try running on latest development (v0.11.3 at the time of this writing) and see if the issue is fixed. A lot of performance/memory enhancements are being worked on that may help your issue.
I guess you have somewhere a memory leak (in form of a closure?) that keeps the (not longer used?) diagrams(?) somewhere in memory.
The v8 sometimes needs a bit tweaking when it comes to > 1 GB of memory. Try out --noincremental_marking and/or --max_old_space_size=81920000 (if you have 8 GB available).
Check for more options with node --v8-options and go through the --trace*-parameters to find out what slows down/stops node.
HI All,
Using ANTS memory profiler, I noticed that in a process of creating Excel file using EPPLUS(3.5 MB) on IIS, a lot more memory (150MB) is added to IIS Worker Process (w3wp.exe). The memory count does not go down after a download is completed. I use pretty much the same code as this one: http://epplus.codeplex.com/SourceControl/changeset/view/c5783b32e89e#SampleApp/Sample1.cs.
EPPLus has everything I need. Except this little problem. I have also seen a few "out-of-memory" threads and none of them seems to be resolved. Please let me know if someone has faced the same issue and fixed it.
Generation 2 is holding lot of objects.
Problem: ExcelCell Object is held in generation 2. How can i clear this without calling GC.Collect()
Thank you.
In a huge C++ builder 2010 application with several DLL's being built and linked etc. What would be the best way to trace down memory leaks that accumulate over a long period of time? Say that the application has to be running for a week or something on the target machine before it becomes an issue. Let's assume that there is no profiling application available like AQ Time or something similar. Just using the standard IDE and perhaps some code.
My initial idea was to write a macro to use in all classes that keeps track of the number of instances and space used of each class type to start with.
The RTL uses FastMM as its memory manager. FastMM supports memory leak reporting and tracing. The native version of FastMM that is included in the RTL is a stripped down version, but it does support minimal leak reporting. You can set the RTL's global ReportMemoryLeaksOnShutdown variable to true at run-time and FastMM will generate a basic leak report when the app is closed. For more advanced usage, you can download the full version of FastMM and add it to your app, which will replace the RTL's native version. You can then configure FastMM as desired.
We have .NET application (actually an IronPython app). We noticed that overtime the app becomes bigger in memory and sluggish.
Using WINDBG (!eeheap -loader), we noticed the that the LoaderHeap is getting bigger (150MB increase per day). From the !eeheap output it seems that the increase is due to HostCodeHeap (objects?).
I'd like to know what are these objects and why how can I prevent them from growing to infinity.
Thanks!
They are likely objects created for dynamically emitted code. Several components in the framework do this, and it may well be that IronPython uses some on its own.
I'd heard of similar issues while using Linq-TO-SQL, XML serialization, compiled XSLT transforms and other dynamically generated code.
See also "Leaking Unmanaged Heap Memory" near figure 2 in this MSDN magazine article.