PDFsharp & MigraDoc Foundation

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

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

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

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.

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


Regards,
André

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.

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é

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

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:
It took nearly half an hour on my workstation to render a table with just about 360 rows
When I changed type of "index" field from NBool to bool? and replaced your code with:
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?

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.

_________________
Regards
Thomas Hoevel
PDFsharp Team

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!

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é

Hello AnKor,

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

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.

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.

excellent, as long as the community gets its feedback.

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.

Has there been any progress yet?

Regards,
André

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?

Any news on performance? this is also killing me!

+1

TIA

Are there any news for this Toppic??

i still have problems in some cases with RenderDocument.


Or did someone see any problem in the Code?

Thx
magges