Date: Fri, 11 Mar 2005 19:10:51 +0100 (CET)
Message-Id: <20050311.191051.74719537.oandrieu at nerim.net>
To: rich at annexia.org
Cc: lablgtk at math.nagoya-u.ac.jp
Subject: Re: Inserting rows into GTree.tree_store is slow
From: Olivier Andrieu <andrieu at ijm.jussieu.fr>
In-Reply-To: <20050311123224.GA786 at furbychan.cocan.org>
References: <20050311003216.GA31634 at furbychan.cocan.org>
	<423167AC.5060900@wanadoo.fr>
	<20050311123224.GA786@furbychan.cocan.org>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

 > Richard Jones [Fri, 11 Mar 2005]:
 > On Fri, Mar 11, 2005 at 05:41:00PM +0800, Arnold wrote:
 > > Inserting a lot of rows is quite slow if a #GTree.model is
 > > "attached" to a GTree.View.
 > 
 > Thanks for the various tips.  Detaching the model from the view
 > didn't actually make much difference, but as a result of testing
 > this I found the real problem, and it appears to be an issue in
 > lablgtk2 itself.

Yeah, IIRC the update of view is done in an idle handler, so detaching
the model shouldn't make much of a difference.

 > The attached program demonstrates the problem.  In that program,
 > each tree row has a "hidden" data cell of type Gobject.Data.caml.
 > It appears that this hidden cell is causing the performance
 > problems.
 > 
 > Without the data cell, the test takes 11 second to insert 50,000 rows.
 > 
 > With the data cell, the test takes 192 seconds to insert 50,000 rows.
 > 
 > The slowdown factor is around x 17.
 > 
 > Unfortunately my original program kind of depends quite fundamentally
 > on having the hidden data cell.  Any suggestions for ways to speed it
 > up would be useful.

yeah the Gobject.Data.caml converter puts a lot of strain on the GC
(it registers one root per value). Maybe it wasn't such a good idea
after all. 

I'd suggest using a basic integer column instead of directly storing
the caml value : then you can fetch the real caml data from a hash
table. It's a bit more painful because you have to take care of
insresting/removing the values in the hashtable.

-- 
   Olivier