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

Paul Barrass paul.barrass at safeonlinebilling.com
Mon Oct 27 07:58:07 EDT 2008


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

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

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.

More information about the reportlab-users mailing list