PDFsharp - moved to http://forum.pdfsharp.net/

JSticksel · Joined: 19 Jan 2007 Posts: 1

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

Thomas Hoevel · Joined: 16 Oct 2006 Posts: 387 Location: Cologne, Germany

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.
_________________
Regards
Thomas Hoevel
PDFsharp Team

matti2 · Joined: 05 Feb 2007 Posts: 3

Noticed this problem. Hope that the rendering will be improven, my whole application is based on tables (pdfsharp is only used for generating reports...)

Stefan Lange · Joined: 12 Oct 2006 Posts: 47 Location: Cologne, Germany

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.

aknuth · Joined: 23 Mar 2007 Posts: 16 Location: Berlin

Hi there,
if you need a quick solution, edit the MigraDoc.Rendering.FontHandler Class:

afzal_aziz · Joined: 16 Aug 2007 Posts: 1

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.

aknuth · Joined: 23 Mar 2007 Posts: 16 Location: Berlin

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é

Roland · Joined: 16 Oct 2007 Posts: 1

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 Shocked

)
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.

AnKor · Joined: 23 Oct 2007 Posts: 3

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:

Thomas Hoevel · Joined: 16 Oct 2006 Posts: 387 Location: Cologne, Germany

AnKor · Joined: 23 Oct 2007 Posts: 3

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! Smile

aknuth · Joined: 23 Mar 2007 Posts: 16 Location: Berlin

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é

Stefan Lange · Joined: 12 Oct 2006 Posts: 47 Location: Cologne, Germany

Hello AnKor,

it is very interesting that MigraDoc becomes 10 times faster with your optimization.

AnKor · Joined: 23 Oct 2007 Posts: 3

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.

aknuth · Joined: 23 Mar 2007 Posts: 16 Location: Berlin

excellent, as long as the community gets its feedback.

Seb' · Joined: 20 Nov 2007 Posts: 1

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.

aknuth · Joined: 23 Mar 2007 Posts: 16 Location: Berlin

Has there been any progress yet?

Regards,
André

Partenon · Joined: 06 Feb 2008 Posts: 1

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?

Jonesy · Joined: 13 Oct 2008 Posts: 1

Any news on performance? this is also killing me!

dvh · Joined: 14 Oct 2008 Posts: 4