View previous topic :: View next topic |
Author |
Message |
JSticksel
Joined: 19 Jan 2007 Posts: 1
|
Posted: 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
Last edited by JSticksel on Mon Aug 20, 2007 8:39 am; edited 1 time in total |
|
Back to top |
|
|
Thomas Hoevel
Joined: 16 Oct 2006 Posts: 387 Location: Cologne, Germany
|
Posted: 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. _________________ Regards
Thomas Hoevel
PDFsharp Team |
|
Back to top |
|
|
matti2
Joined: 05 Feb 2007 Posts: 3
|
Posted: 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...) |
|
Back to top |
|
|
Stefan Lange
Joined: 12 Oct 2006 Posts: 47 Location: Cologne, Germany
|
Posted: 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. |
|
Back to top |
|
|
aknuth
Joined: 23 Mar 2007 Posts: 16 Location: Berlin
|
Posted: 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é |
|
Back to top |
|
|
afzal_aziz
Joined: 16 Aug 2007 Posts: 1
|
Posted: 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. |
|
Back to top |
|
|
aknuth
Joined: 23 Mar 2007 Posts: 16 Location: Berlin
|
Posted: 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é |
|
Back to top |
|
|
Roland
Joined: 16 Oct 2007 Posts: 1
|
Posted: 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 )
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. |
|
Back to top |
|
|
AnKor
Joined: 23 Oct 2007 Posts: 3
|
Posted: 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
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? |
|
Back to top |
|
|
Thomas Hoevel
Joined: 16 Oct 2006 Posts: 387 Location: Cologne, Germany
|
Posted: 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. _________________ Regards
Thomas Hoevel
PDFsharp Team |
|
Back to top |
|
|
AnKor
Joined: 23 Oct 2007 Posts: 3
|
Posted: 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! |
|
Back to top |
|
|
aknuth
Joined: 23 Mar 2007 Posts: 16 Location: Berlin
|
Posted: 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é |
|
Back to top |
|
|
Stefan Lange
Joined: 12 Oct 2006 Posts: 47 Location: Cologne, Germany
|
Posted: 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. |
|
Back to top |
|
|
AnKor
Joined: 23 Oct 2007 Posts: 3
|
Posted: 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. |
|
Back to top |
|
|
aknuth
Joined: 23 Mar 2007 Posts: 16 Location: Berlin
|
Posted: Mon Nov 12, 2007 4:20 pm Post subject: |
|
|
excellent, as long as the community gets its feedback. |
|
Back to top |
|
|
Seb'
Joined: 20 Nov 2007 Posts: 1
|
Posted: 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. |
|
Back to top |
|
|
aknuth
Joined: 23 Mar 2007 Posts: 16 Location: Berlin
|
Posted: Mon Dec 17, 2007 8:33 pm Post subject: |
|
|
Has there been any progress yet?
Regards,
André |
|
Back to top |
|
|
Partenon
Joined: 06 Feb 2008 Posts: 1
|
Posted: 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? |
|
Back to top |
|
|
Jonesy
Joined: 13 Oct 2008 Posts: 1
|
Posted: Mon Oct 13, 2008 1:19 pm Post subject: |
|
|
Any news on performance? this is also killing me! |
|
Back to top |
|
|
dvh
Joined: 14 Oct 2008 Posts: 4
|
Posted: Wed Oct 15, 2008 10:50 am Post subject: |
|
|
Jonesy wrote: | Any news on performance? this is also killing me! |
+1
TIA |
|
Back to top |
|
|
|