[reportlab-users] Tons of table questions

[Robin Becker]

Dinu Gherman wrote:

> Henning von Bargen:

> 

>> I guess that further optimization requires additional conditions:

>> 1) The first and all the following frames have to be of the same width.

>> 2) Possibly:  ... the same height.

>>

>> But for long tables, at least condition 1) should be no problem

>> for real-world applications.

> 

> I think both conditions are very realistic in practice.

> But even without them I cannot see any non-linearity re-

> lated to the problem itself. So, maybe an implementation

> using generators might solve this?

> 

> Dinu

.......
I don't think it much matters whether you use generators or something else to 
hold the actual data. What matters is to reduce or eliminate the copying.

The longTable n**2 problem relates to copying the data which is of order n-m 
where m is the number of data rows already dealt with. Since you need to do that 
operation some fraction of n times you get a term in (n-p) + n-2p + n-3p ..... 
which sums to O(n**2).

By putting the tail of the data into a generator (+a lookahead buffer for the 
bits discarded by the current table) the n-m term is indeed reduced, but you 
still have to copy the data around. So the split would look like

T0(B=[],G)

    -->      T1(B=[1...p],None) + T2(B=[p+1,..],G)

where B represent s a buffer of rows popped from the generator, but not yet 
rendered and G represents the tail of the data. Clearly you have to copy the 
[p+1,..p+x] rows that are unused from T1. Hopefully this copying is small (say 
only one overflow row).

If you use a data array or simulation thereof you can represent the split as

T0(1,len(A),A)

    -->     T1(1,p,A) + T2(p+1,len(A),A)

so no copying is required, but we change the view indices as we go forward.
-- 
Robin Becker