[reportlab-users] Large tables - exponentially increasing run times

[Andy Robinson]

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.

Henning von Bargen's contribution was folded into  the
code in a 'temporary way' some months back so it would
not affect any live documents:

> class LongTable(Table):
> 	'''Henning von Bargen's changes will be active'''
> 	_longTableOptimize = 1
> 

However, I think having a separate class for the sake of
one attribute is overkill. It should just be an attribute
of the standard table class.  Robin, could you change this?

Now for the default value. 
Do we lose any funtionality by turning this flag on
(i.e. does it not split or size correctly)?  The one
I am aware of is that if you only examine the first
few rows and you have auto column widths, it won't
spot the extra wide cell in row 61543, so widths
of columns on later pages.

If there is no major loss of functionality then let's 
make the default 1.  If there is, let's make it 0.
Either way we need a section in the user guide explaining
about this parameter, and also explaining that separate
mini tables will always be a safe and fast way to handle
huge tables.

Thanks,

Andy