From: Martin Sevior (email@example.com)
Date: Thu Oct 02 2003 - 23:27:39 EDT
On Fri, 2003-10-03 at 08:00, Robert Wilhelm wrote:
> On Thu, 2003-10-02 at 15:31, firstname.lastname@example.org 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.
> #if 1
> [...] deleteBrokenTables [...]
> Maybe Martin can elaborate a bit on this issue.
Thanks very much for the info. This helps a lot. I think we
don't need to deleteBroken Tables during import. I'll see if we can do
away with this.
In addition this also points out where I need to focus to improve
editting performance on large documents with tables.
This archive was generated by hypermail 2.1.4 : Thu Oct 02 2003 - 22:41:50 EDT