Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Don Allingham <donaldallingham <at> comcast.net>
Subject: Re: [Gramps-users] Gramps vs BIG database
Newsgroups: gmane.comp.genealogy.gramps.devel
Date: Monday 15th January 2007 22:11:10 UTC (over 10 years ago)
On Mon, 2007-01-15 at 15:59 -0500, Douglas S. Blank wrote:
> 
> Gramps should be able to handle that, eventually. One of the first steps
> would be to develop an API that does not require the programmer to work
> with gramps' "handles." These are internal references and should not be
> seen. Once that happens, then the data could be in a SQL database, or
> something else.
> 
> -Doug

Do not expect an SQL database to make things faster. In fact, expect it
to make things slower.

GRAMPS is built using a low level database (Berkeley DB). This is the
type of database that SQL databases are built on top of. Remember the
concern several months ago when Oracle bought the Berkeley DB and people
were concerned how this would affect MySQL? Putting an SQL in GRAMPS
would be just adding another layer.

The GRAMPS handle is nothing more than the database index. Since we use
a hash implementation, linear numbers are not good. You have to have
*something* to reference an entry, and our handle is just that.

As several people have pointed out, the performance is *not* a database
issue. When you are scrolling the window, we are actually accessing the
database on the fly to build the data in the display.

The time comes from having to map the data into something the TreeView
can handle. The TreeView requires us to map the least amount of data at
a time.

We use an LRU cache algorithm to minimize the amount of time accessing
data and building displays. But it all comes down to the fact that the
TreeView/ListView in GTK have some performance issues.

Don
 
CD: 2ms