My app will typically work with 6 workbooks instantiated (one window each) simultaneously.
User will work interactively with the worksheets, just like he would if Excel was used.
After some editing, he/she will perform some heavy access of data (mostly reading), processing the data and send the outputs to another application (as xml documents by COM interface)
As a test I instantiate 6 spreadsheets, one window each and load them with the same xlsx file.
The loaded workbook filesize is about 430 kBytes and contains 37 worksheets (no graphs or other graphics, just plain worksheets) with a total of 45520 cells with data and 1489 formulas (according to Excel/Review/Workbook Statistics) .
My testmachine has an i7-8700 cpu (6 cores) and available memory before application start of about 24 GBytes of rwm.
The opening time until all 6 spreadsheets are visible and editable on screen is about 90 seconds and final working set is about 1.4 GBytes(!!).
Using Excel 2021/x64 and opening the same 6 workbook instances (6 different copies to enable single process) takes about 6 seconds with final working set of 237 MBytes.
The cpu load while editing the workbooks seems to be much more demanding than Excel as well, not really measured, probably acceptable.
Accessing cells data (reading plain cell data) seems to be doable with acceptable performance.
The long loading time and the high memory demand is not acceptable and means that I cannot use WPF radSpreadsheet as is and will need advice to lower these numbers if possible.
Alternatives are:
Using Excel (accessing with Excel COM automation), but I would very much like to avoid the license cost (and more complex application
development).
Finding another component supplier, similar to Telerik radSpreadsheet, but with possibly better performance (I guess it is not proper to ask in this forum for advice of which supplier could be recommended :)
Hello Magne Ryholt,
Could you share more information on your setup, like, for example, do you use a Ribbon in all of your windows, do you use the StyleGallery in your Ribbon? Is the initial loading time the most significant issue? Is the 1.4GB memory allocated right after importing the documents or after some UI interactions? Could you share a sample document and/or project? The more information you provide, the easier it would be for us to reproduce the issue and possibly provide you with a workaround or a fix.
Ribbon is used in all windows (actually I am talking about 6 instances of the same window class, just loaded with different xlsx files).
Both the loading time and the memory demand are probably "showstoppes" for me.
The memory allocation is right after loading xlsx files, before any user interface actions.
I can probably make a a sample for sharing with you, but I must change the data in thw workbooks, they are customer data so i must make a dedicated set of test workbooks for you, will try later on today. Loading time and memory allocated wil probably differ a bit from earler mentioned, but it will be useful as a issue repro.
Furthermore, I can inform that using DevExpress spreadsheet control and the same set of workbooks is 15 times faster to load and show and with memory allocation of only about 20% of Telerik's on par with Excel)
To make "anonymous" test workbooks I created (using Excel) 5 workbooks which I thought would resemble my real case.
Just about the same amount of sheets in each book as the real case,
just about the same amount of cells in each sheet as the real case.
Each cell populated with a string according to this pattern: "Book<x>.Sheet<y>.Cell<z1>_<z2>"
This time they load in about 13 seconds which is probably acceptable and with allocated memory of about 615 MBytes (still high and probably unacceptable), however it seems like my test books do not resemble the actual case..
Perhaps because test books don't contain any formulas?
Perhaps there is some optimization loading strings with only small variations (I have no idea of how though)
Could you try removing the Ribbon or just the StyleGallery from it? The StyleGallery is working slowly because it makes screenshots of the cells, taking time.
If you open a support ticket, you could upload the original file there. This way, it will not be public to all people reading the forums. Point 1.11 of our EULA forces us to treat all information shared by our clients strictly confidentially.