OpenXmlPackage.Save is increasingly slow as number of objects increases
Home › Forums › Open-Xml-Sdk › OpenXmlPackage.Save is increasingly slow as number of objects increases
This topic contains 2 replies, has 2 voices, and was last updated by Tim Dol 4 years, 1 month ago.
-
AuthorPosts
-
September 8, 2020 at 2:47 pm #9682
Hi,
Don’t ask me why, but on my project I create PowerPoint slide decks with hundreds of slides, with 50-70 shapes each.
What we are experiencing, is that PresentationDocument.Save is increasingly slow as the number of slides in the slide deck increases. For ‘smaller’ slide decks, .Save processes approximately 1.7 slide per second.
With 350 slides, that slows down to 1.5 slide per second, and with 1.750 slides, we’re at .3 slides per second (that is, 1.5 hours to save the file on a mobile workstation).Anyone who can provide some insight why the time required is not linearly related to the number of objects? We are targeting to limit slide decks to 500 slides, but with 7 minutes to save such a file this is becoming an issue. We will look into creating them in parallel (@Eric, thanks for http://www.ericwhite.com/blog/supporting-ultra-high-performance-open-xml-document-generation/).
But is there anything to improve performance on a single thread?Tim
October 7, 2020 at 10:57 am #9743
AnonymousWCF isn’t necessarily slow but if the application isn’t designed properly, the application can be slow. It could be compared to loading up a few thousand pounds of weight on a sports car. The car is a fast car, but it isn’t really being used properly.
First, I would say you have to minimize the amount of data that is being sent on the wire (more about this later). Once on the wire, you’ll get a lot better performance if you use TCP or named pipes instead of HTTP. See Choosing a Transport. HTTP is easy since most networks are configured to let is past easily but it isn’t designed for large data sets.
If the delay is coming from the calculations, then the only thing the WCF service will accomplish is offloading the processing from the server to the client. Ultimately this might be a good thing – or even necessary – if you plan on having a high volume of concurrent requests to the server but as you have noticed, it doesn’t necessarily mean shorter times for the end user. What you should focus on doing is minimizing the calculation time.
It is hard to give specifics since you havent revealed much about what is being queried, what is being returned and the the calculations are doing. However, I have had impressive results with large data sets by offloading code from the application server to the database server via Visual Studio SQL Server Projects. Since .NET and MSSQL are both written on the CLR, you can write native database objects (like user defined functions) in C# or VB or any other CLR language and deploy them directly into the database. Then you can use these functions in your queries and they are very fast since they are compiled into native SQL. I’ve seen orders of magnitude in difference between running C# in the application vs running the same function in the database.
October 7, 2020 at 11:22 am #9746Thanks for the input. Unfortunately, this has nothing to do with wcf. Just the .SaveAs() command of the PresentationDocument class, even if you save to a local drive.
-
AuthorPosts
You must be logged in to reply to this topic.