[reportlab-users] Potential workaround for performance issues on VERY long tables.

[Paul Barrass]

Hi,

There's been discussion in the past regarding the relatively poor 
performance of ReportLab for very long tables (10's-100's of 1000's of 
lines).  Way back in 2004, the official response 
(http://two.pairlist.net/pipermail/reportlab-users/2004-May/003019.html) was

'John has hit on the "official" answer - make lots of small tables. The 
only case I can see for not doing this is when you need a repeated table 
header.'

I've recently run into the same problem - I was previously able to split 
the table into small tables of a fixed length by ensuring that all 
tables started on a new Frame, and fixing the rowHeights.  That's no 
longer possible, as I've lost both of those constraints.  I have found a 
workaround that allows me to split the table but still have a repeated 
table header. In the hope that it may be useful to others, I'll detail 
it below.

This workaround requires that you are able to specify the widths of all 
the columns, but works where the heights of the rows are calculated.  As 
in the "official" answer, make lots of small Tables  (I find aiming to 
have roughly a pages-worth of rows per table seems to give the best 
performance - which is to be expected since the performance hit is in 
the splitting) without any header and a separate table containing just 
the header. Simply wrap each of the Tables in a PTOContainer (from from 
reportlab.platypus) giving the header table as the header to the 
PTOContainer.

I'm sure there are many cases where this won't work or just look wrong - 
but in simple cases where you have lots of rows with simple styling and 
you just need a repeated header row, the above gives a noticeable 
performance boost for the same end effect.

Apologies if this has already been discussed/solved before, but if it 
has I've not been able to find the discussion (and believe me, I've been 
looking... :) ).  If the hint is useful, I'd be happy to see it make 
it's way into the documentation.

Paul Barrass.