PDFsharp & MigraDoc Foundation
http://forum.pdfsharp.de/

Slow Rendering of large tables with many columns
http://forum.pdfsharp.de/viewtopic.php?f=2&t=55		 Page 1 of 1
Author:  JSticksel [ Fri Jan 19, 2007 8:10 am ]
Post subject:  Slow Rendering of large tables with many columns
I have a Question about the time to render large tables.
I have modified the "invoice" example from MigraDoc-Lite and add some more columns to the table (all together 17). Then I wrote a loop to add 500 rows of (dummy) content to the table.
The renderer now needs about 10 Minutes to render the File. Is it possible to reduce this timespan?

Thanks for Help!

J. Sticksel
Author:  Thomas Hoevel [ Fri Jan 19, 2007 9:39 am ]
Post subject: 
Table rendering is a bit slow, but we haven't investigated that problem yet.
I think we can speed it up quite a bit, but I'm afraid we won't have time for that in Q1/2007.

Processing time is OK on my 3 GHz workplace computer, but is a pain on our 500 MHz test computer.
Author:  matti2 [ Wed Feb 07, 2007 2:11 pm ]
Post subject: 
Noticed this problem. Hope that the rendering will be improven, my whole application is based on tables (pdfsharp is only used for generating reports...)
Author:  Stefan Lange [ Thu Mar 08, 2007 11:24 pm ]
Post subject: 
Yes, the performance of rendering tables is extreamly lousy.
One problem is that creating a font is an expensive operation. The Invoice sample create 1800 times an XFont, Hello MigraDoc over 7200 times, and even Hello World creates 14 times a new font. This is not acceptable. I put it on the bug list. We will release an update immediately when we have fixed it.
Author:  aknuth [ Sat Mar 24, 2007 5:35 pm ]
Post subject: 
Hi there,
if you need a quick solution, edit the MigraDoc.Rendering.FontHandler Class:
Code:
      private static Dictionary<string, XFont> _FontCache = new Dictionary<string, XFont>();

      /// <summary>
      /// Converts an DOM Font to an XFont.
      /// </summary>
      /// <param name="font"></param>
      /// <returns></returns>
      internal static XFont FontToXFont(Font font, bool unicode) {
         string key = font.Name + "#" + font.Size + "#" + GetXStyle(font);

         if (_FontCache.ContainsKey(key)) {
            XFont cachedFont = _FontCache[key];
            return cachedFont;
         }

         XPdfFontOptions options = null;
         if (unicode) {
            options = new XPdfFontOptions(false, true);
         }

         XFontStyle style = GetXStyle(font);
         XFont xFont = new XFont(font.Name, font.Size, style, options);
         _FontCache.Add(key, xFont);
         return xFont;
      }


Regards,
André
Author:  afzal_aziz [ Mon Aug 20, 2007 7:46 am ]
Post subject:  On table creation
Mr. André (aknuth) can u mention what change needs to be done to make the table rendering faster in PDF sharp?

I had changed the code accordingly as u had mentioned but still the performance is extremely slow.

It takes around 2 min to create table with 6 col in 3 pages. Unless the performance is improved , I will not be able to use it.
Author:  aknuth [ Mon Aug 20, 2007 6:48 pm ]
Post subject: 
the improvement i suggested speeds up the font allocation, I dunno any in depth details of the rendering process, so reasons for further slow rendering are beyond my knowledge, sorry.

regards,
andré
Author:  Roland [ Tue Oct 16, 2007 12:14 pm ]
Post subject: 
Sry, but this problem has nothing to do with fonts, etc.

Its more difficult. The MicraDoc Lite engine uses reflection to access any property of the internal DOM by MetaData and Attributes.

We used JetBrains .NetTrace to analyse the bottlenecks. It clearly shows, that for a table with about 1000 rows and 3 columns more than 12-14 million reflection operations (for only two properties!!) will be evaluated.
Named the generic get/set operators "setValue" and "getValue" of nullable types. (btw: which are not implemented as "nullable types". They really implemented an custom attribute system to mimic this feature :shock: )
And that is the real problem.

The MicraDocLite engine does even not use any kind of caching to improve the performance for reflection operations.

For this, a quick solution can not be found. The only way would be to implement a kind of caching or generally avoid the usage of reflection here.
Author:  AnKor [ Tue Oct 23, 2007 3:19 pm ]
Post subject: 
Hello,

There's definitely serious performance problem with rendering large tables. And Roland is right - the main bottleneck is overuse of reflection. For example, the most common operations is to get an index of a column (or a row) looks like:
Code:
        if (IsNull("Index"))
        {
          Columns clms = this.Parent as Columns;
          SetValue("Index", clms.IndexOf(this));
        }
        return index;
It took nearly half an hour on my workstation to render a table with just about 360 rows :shock:
When I changed type of "index" field from NBool to bool? and replaced your code with:
Code:
       if (index == null)
       {
           Columns clms = (Columns)this.Parent;
           index = clms.IndexOf(this);
       }
       return index;
Now it works like 10 times faster! And takes about 3-4 minutes to render the same table which is still too bad.

I can imagine that you wanted to make your engine more flexible with these field but why reflection, why not dictionary, for example?

Also I wonder why do you use "home made" INullable interface instead of nullable types?
Author:  Thomas Hoevel [ Tue Oct 23, 2007 3:43 pm ]
Post subject: 
AnKor wrote:
Also I wonder why do you use "home made" INullable interface instead of nullable types?

Thanks to you and Roland for pointing out the bottlenecks.

PDFsharp was written with and for .NET 1.1.
Nullable Types were introduced with .NET 2.0 - along with many other useful generic types.

PDFsharp no longer supports .NET 1.1 and we have begun to use some of the new generic types in PDFsharp.
Author:  AnKor [ Tue Oct 23, 2007 3:54 pm ]
Post subject: 
Unfortunately this will be lots of work to change NSomething to nullable types.

Anyway, your library looks very good and I think I'll manage to make its performance suitable for my project! Thanks! :)
Author:  aknuth [ Wed Oct 24, 2007 1:01 pm ]
Post subject: 
Hi AnKor,
could you please let others participate in the performance enhancements? That would be very helpful even it is - and hopefully is - only a short term solution.
Regards,
André
Author:  Stefan Lange [ Wed Oct 24, 2007 7:47 pm ]
Post subject: 
Hello AnKor,

it is very interesting that MigraDoc becomes 10 times faster with your optimization.
Quote:
but why reflection, why not dictionary

An earlier implementation of MigraDoc was based on our internal framework which uses reflection combined with a smart caching algorithm. Before we made MigraDoc Open Source, we decided to rewrite the framework code we need in MigraDoc. Because of limited resources the implementation of the object model is just semantically correct, but far beyond from optimal.

Is it possible that you send me your modified version of MigraDoc? I would like to make some tests. If everything works fine, we will refactor the object model and release it as soon as possible.

If you like just send the code to Stefan.Lange@pdfsharp.com.
Author:  AnKor [ Mon Nov 12, 2007 2:19 pm ]
Post subject: 
I'm back :)

Stefan,
I've sent you an email with my changes.

aknuth,
Perhaps, you're right and I should publish my modifications, but they're very incomplete and I think I better let authors to review them first.
Author:  aknuth [ Mon Nov 12, 2007 4:20 pm ]
Post subject: 
excellent, as long as the community gets its feedback.
Author:  Seb' [ Tue Nov 20, 2007 6:11 pm ]
Post subject: 
Hi AnKor,

I would be glad to see your modifications for this table rendering performance issue. PdfSharp is really a nice lib, but this slow rendering is really problematic in production.

Could you please send me your source code at : sbaviere [at] premiumconsulting [dot] fr ?

Thanks.
Author:  aknuth [ Mon Dec 17, 2007 8:33 pm ]
Post subject: 
Has there been any progress yet?

Regards,
André
Author:  Partenon [ Wed Feb 06, 2008 9:03 am ]
Post subject:  Progress ?
We are about to choose a pdtWriter for an upcoming project, and I've been evaluating PDFsharp (with MigraDoc) and the performance with tables is really a big issue. Our report will be hundreds of pages and just testing a table spanning 10 pages took about 7s to generate (on our Intel Core 2 QUAD).

As I understand this has been an issue for years?
Author:  Jonesy [ Mon Oct 13, 2008 1:19 pm ]
Post subject: 
Any news on performance? this is also killing me!
Author:  dvh [ Wed Oct 15, 2008 10:50 am ]
Post subject: 
Jonesy wrote:
Any news on performance? this is also killing me!

+1

TIA
Author:  Magges [ Thu Mar 24, 2011 11:24 am ]
Post subject:  Re: Slow Rendering of large tables with many columns
Are there any news for this Toppic??

i still have problems in some cases with RenderDocument.
Code:
            myMigraDocument.UseCmykColor = True
            myMigraDocument.Info.Title = myValueFromForm_docName
            myMigraDocument.Info.Author = System.Environment.UserName

            myMigraDocument.Info.Comment = myArchivHandler.getValueFromForm_Comment

            Const unicode As Boolean = False
            Const embedding As PdfFontEmbedding = PdfFontEmbedding.Always

            ' Create a renderer for the MigraDoc document.
            Dim pdfRenderer As PdfDocumentRenderer = New PdfDocumentRenderer(unicode, embedding)

            ' Associate the MigraDoc document with a renderer
            pdfRenderer.Document = myMigraDocument

            ' Layout and render document to PDF
            pdfRenderer.RenderDocument()

            ' Save the document
            pdfRenderer.PdfDocument.Save(pFileName)



Or did someone see any problem in the Code?

Thx
magges
Page 1 of 1 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/