From: Robert Wilhelm (firstname.lastname@example.org)
Date: Thu Oct 02 2003 - 18:00:29 EDT
On Thu, 2003-10-02 at 15:31, email@example.com wrote:
> 2. Try profiling the layout fill phase to see if there is anything in
> particular that is a bottleneck. We're currently using the GTK table
> layout algorithim which is extremely robust but might be the cause of the
> slow fill time in the those huge tables.
About half of the layout fill phase is spent in
fpTableContainer::deleteBrokenTables. This recursive function
is invoked about 65M times :-(
In fp_VerticalContainer::bumpContainers there is an interesting
// Experimental code: FIXME: Might remove after a while - check
// that large tables broken over many pages work fine.
[...] deleteBrokenTables [...]
Maybe Martin can elaborate a bit on this issue.
This archive was generated by hypermail 2.1.4 : Thu Oct 02 2003 - 18:23:05 EDT