Hi,
In the "Why Aspose.Office is a better option than Office automation… " section of your website, you describe the problems with the Microsoft .NET Excel Object Model, and give a high level, generalized description of how Aspose does not have these problems.
Can you give me some low level technical information on HOW Aspose is designed to resolve these issues? Some benching marking values would be nice ( ie how much time it takes for Aspose to export a massive number of records into Excel, vs how fast Office Automation is for the same dataset, or stress test analysis on how many users can export at the same time with Aspose.Excel). I have tried out Aspose.Excel, Aspose.Pdf and Aspose.Email. They seem to work ok with some simple examples that I have available. However, we don’t know how it will behave with a huge amount of data and on a large scale of concurrancy. We don’t currently have the resources to be able to simulate these conditions to stress test Aspose. We at Watchfire are very interesting in purchasing your product, and it would extremely beneficial to us if you can provide some bench marking information to prove that Aspose will work as expected when stress tested.
Thank you.
Hi Kristy,
Aspose.Excel is totally built on .NET platform. It avoids the weak points of automation.
When we designed Aspose.Excel, we carefully considered the performance issue and memory usage to make it suitable for using in server side.
Many customers used Aspose.Excel in their server side applications. Some benchmark values:
1. An insurance company uses Aspose.Excel to create large complex files. The following is the feedback information:
A single thread application:
"Some reports execute in 7 seconds, some 30 minutes right now. Let me cheer you up… they currently take up to 2 HOURS using VBA Excel Automation in VB6. These are huge reports depending on what the user selects. The one that I’m re-writing takes 21 minutes and is 19MB. "
And they are porting their applications to a multi-threads environments on a multi-CPU machine. They find: "the speeds are 100 X automation or more."
2. A customer uses Aspose.Excel to add a large number of comments to a file. And he finds it’s 30-100 X fasters than their previous automation program.
3. After stress testing on Aspose.Excel, a customer uses Aspose.Excel in their web farm servers.
Thank you very much for your reply, Laurence. I was wondering whether you can find out from the customer who said their dataset takes 2 HOURS to export using VBA Excel Automation, how large their recordset is? ie how many row and columns ( how many records in total). Also, the one that takes 21 mins and is 19MB…how many record sets is 19MB?
Also, the customer who is using Aspose.Excel in their farm servers…would it be possible to find out how many users access the server?
If you can provide me with any of this information, it would be very helpful. Or if you’re too busy to ask them, maybe you can give me their contact information and I can ask them directly about their test results data?
Thank you.
About the customer who is using Aspose.Excel in their farm servers, I cannot find the contact information for he give me the information about one and a half year ago.
I will provide the information from another customer. Please wait for a few days. Thanks for your patience.
Hello Kristy, my name is Marty Spallone and I’m a US based consultant for Aspose. I help clients with .net architecture and custom Enterprise application software.
I’m developing large reports for a large client in CT and we have essentially built a reporting engine and reporting framework for processing very large back office type reports that go against large OLAP databases (SQL Server 2000). I have been tasked with rewriting several VBA Excel automation reports from [VB6] to VB.NET and Aspose.Excel.
The new reports are about 20 times (at least) faster in a single-threaded model. You have to understand we’re not comparing apples to apples. The old environment was single threaded and ran one report at a time. Today we can create several reports on a threaded basis and run several at a time and we’ve also optimized some of the stored procedures. What I can tell you is that the bulk of the work is in the data layer, i.e. the stored proc because that’s the nature of my client’s data. When you have long running queries like we do, it makes sense to multithread the mutual exclusive queries using the thread pool and then process all the data when all the threads are complete. This way you only need to wait for the longest running thread - with some other overhead but you get the idea.
What I can tell you is that the process of manipulating the data in the business tier and saving the spreadsheet takes about 10% of the time. So, a 21-minute report takes about 2 minutes to save. That is a big report with 65k rows and about 10 other sheets of data, 19MB excel file. Its not your typical report but I think you get the idea.
Please also understand that most of the reports that filter data based on the user’s input are smaller and they run in just a few seconds, but the data services still takes the bulk of the work.
Aspose products are built on Managed code, i.e. CLR, this means that there is no overhead for COM interop, or ActiveX or STA, marshaling etc. Think of it as just accessing collections in memory and since its written in C# my guess is that some operations are done in unsafe code using pointers, which is very fast. The process of writing the file then is streaming the data out to a file in the form of an Excel file-format.
I am in the process of writing some benchmarking examples because many customers ask about the performance aspects. I have written a hires timer for timing mission critical applications because we need 1-ms resolution which as you may know already GetTickCount does not provide. More on this later…
Feel free to contact me or see my blog