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

[Craig Ringer]

On Mon, 2004-05-17 at 14:31, Henning von Bargen wrote:

> I encourage you to use your implementation for your specific problem.

That was the plan. I was posting to see if others had found this to be
an issue. It doesn't seem to be, so there's not much point in bothering
you folks further.

If I get a nicely working Table subclass that doesn't appear to break
anything else, I'll post it in case anybody is interested. I have an
initial one working that seems to work well, but it still needs quite a
bit of work.

> However, as soon as you're going to use more dynamic data
> (with variable length, say, from a database)

The issue I'm working on is _because_ I'm pulling large amounts of data
from a database :-)

Unfortunately, we do need huge tables (and do need repeated rows). It
sounds weird to need to render 50+ page tables really quickly, but it's
something our app needs.

I can work around it by doing my own page height calculations and
creating a small set of "pre-split" tables with the right headings etc,
but I'd like to find a nicer way in case others need to do similar
things later.

> and you want Platypus to calculate row heights itself,
> you will have to format Paragraphs/strings at least one time.
> The LongTable solution does it at most 2 times for each
> cell (0x/1x height calculation, 1x actually drawing).
> Thus it is still not optimal (from a theoretical point of view),
> but it would require a lot of tweaking to further tune it,
> making it hard to read and hard to maintain.

Makes sense.

The main thing that confuses me is why the Table instance being split
creates an entire new Table instance rather than trimming data (and
styles, etc) off its self and returning [R0, self]. I presume it comes
down to the readability and maintainability issues mentioned above.

Craig Ringer