[reportlab-users] Spreadsheet Table

[Robin Becker]

On 23/02/2010 13:48, Tomasz Świderski wrote:
............

> It is hard to compare performance of implementations since reportlab 2.4

> does not contain this patch:

> http://two.pairlist.net/pipermail/reportlab-users/2010-February/009275.html

> but my spreadsheet implementation does. So I decided to compare 3

> versions: spreadsheet, reportlab 2.4 with patch (optimizedlongtable),

> and reportlab 2.4 without patch. Results below:

.........
Tomasz, is this just the normalized data patch. I think that is already in as of 
06/02/2010. If it is wrongly applied somehow can you let me know what's wrong?


As for the generic discussion I believe the original Table was coded for ease of 
the coder and not with any thought about speed etc etc. The long table patches 
were applied to allow for a representative sample of the rows to be used for 
calculating widths. However, it is still fairly inefficient. As I understand it 
we ought to compute the dimensions of each cell up front ie with the minimum 
possible work. The table ought then to mutate into a class which never computes 
anything, but is merely a view onto the computed rows/columns.
Splitting of a view ought to be easy.

That sort of idea ought to work for tables without header/footer rows fairly 
easily. However, when the cells are not statically evaluatable, but may depend 
on their position then things may be harder. If header rows can be assumed to be 
static then splitting is much easier, but say I have a footer row that contains 
the sum of the columns above it on the current page. For example purposes and 
because I'm a martian I decide to show the sums at 90 degrees. As the length of 
the numbers change the footer row height varies; splitting now requires a search 
with repeated evaluation of the footer row.
-- 
Robin Becker