From: Anton H. <ant...@gm...> - 2012-09-30 13:53:20
|
Hello, searching in the database using person view is very slow on all my personal computers and notebooks. For a Surname it takes around 20 seconds until the result is displayed. I've nearly 28000 persons in my database. Is there a way to make searching more comfortable for big database? Best regards, Anton |
From: Benny M. <ben...@gm...> - 2012-09-30 18:02:18
|
2012/9/30 Anton Huber <ant...@gm...> > Hello, > > searching in the database using person view is very slow on all my > personal computers and notebooks. For a Surname it takes around 20 seconds > until the result is displayed. I've nearly 28000 persons in my database. Is > there a way to make searching more comfortable for big database? > It has been some time since we optimized for large databases. So some changes might have crept in that are a disaster on large databases. Are you trying trunk or gramps34? They are quite different at the moment. To speed things up: 1/remove calculated columns, like spouse, ... You can do that in the preferences of the view (icon on toolbar or in menu) 2/make sure the status bar does not compute relationship, or if it does, that it does not scan too many generations back 3/make sure you don't have gramplets that change on change of active person. This can really slow things down, as the gramplet is recomputing on selection of another person in the person view. Especially a descendant gramplet and such can be problems. We have had in the past a large .gramps to test with, but that was generated data, so behaves differently from real genealogical data. I don't have a large dataset to try with at the moment. As you post on the devel list, can you code yourself? To understand where the bottleneck is, we need to add profiling on the searching, see http://www.gramps-project.org/wiki/index.php?title=Debugging_GRAMPS#Use_profiling On trunk, the import statement for that has changed however. Let us know if you are interested in profiling it. Apart from the above, for large datasets, another view which is not a listview would not be bad. A listview after all needs to load a lot of data in memory. Typical view within companies is then a search view, where you give some limitations, and only that piece is obtained from the database, instead of the entire table. It would not be a bad addition to gramps to create such a view. Benny > > Best regards, > > Anton > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Benny M. <ben...@gm...> - 2012-09-30 18:03:58
|
I see we have a GEP here with instructions on profiling that are perhaps easier: http://www.gramps-project.org/wiki/index.php?title=GEPS_016:_Enhancing_GRAMPS_Processing_Speed Benny 2012/9/30 Benny Malengier <ben...@gm...> > > > 2012/9/30 Anton Huber <ant...@gm...> > >> Hello, >> >> searching in the database using person view is very slow on all my >> personal computers and notebooks. For a Surname it takes around 20 seconds >> until the result is displayed. I've nearly 28000 persons in my database. Is >> there a way to make searching more comfortable for big database? >> > > It has been some time since we optimized for large databases. So some > changes might have crept in that are a disaster on large databases. > > Are you trying trunk or gramps34? They are quite different at the moment. > > To speed things up: > 1/remove calculated columns, like spouse, ... You can do that in the > preferences of the view (icon on toolbar or in menu) > 2/make sure the status bar does not compute relationship, or if it does, > that it does not scan too many generations back > 3/make sure you don't have gramplets that change on change of active > person. This can really slow things down, as the gramplet is recomputing on > selection of another person in the person view. Especially a descendant > gramplet and such can be problems. > > We have had in the past a large .gramps to test with, but that was > generated data, so behaves differently from real genealogical data. I don't > have a large dataset to try with at the moment. > > As you post on the devel list, can you code yourself? To understand where > the bottleneck is, we need to add profiling on the searching, see > > http://www.gramps-project.org/wiki/index.php?title=Debugging_GRAMPS#Use_profiling > On trunk, the import statement for that has changed however. Let us know > if you are interested in profiling it. > > Apart from the above, for large datasets, another view which is not a > listview would not be bad. A listview after all needs to load a lot of data > in memory. Typical view within companies is then a search view, where you > give some limitations, and only that piece is obtained from the database, > instead of the entire table. It would not be a bad addition to gramps to > create such a view. > > Benny > >> >> Best regards, >> >> Anton >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://ad.doubleclick.net/clk;258768047;13503038;j? >> http://info.appdynamics.com/FreeJavaPerformanceDownload.html >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> > |
From: Jérôme <rom...@ya...> - 2012-10-01 07:20:09
|
> For a Surname it takes around 20 seconds until the > result is displayed. I've nearly 28000 persons in my database. "Flat views are faster than Tree views" http://www.gramps-project.org/wiki/index.php?title=Tips_for_large_databases Try to rather to "display Surnames" via person list view! Surnames will not be grouped (parent node), but I know that it will be faster. Note, I got this problem with Place Tree View in the past (around 38 000 rows/entries) and I did not test Citations/Sources Tree View yet, which seems to use an other method (iteration, cursor) for displaying such grouped data. Jérôme Le 30/09/2012 15:53, Anton Huber a écrit : > Hello, > > searching in the database using person view is very slow on all my personal > computers and notebooks. For a Surname it takes around 20 seconds until the > result is displayed. I've nearly 28000 persons in my database. Is there a > way to make searching more comfortable for big database? > > Best regards, > > Anton > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Dave B. <thi...@gm...> - 2012-10-11 03:01:55
|
Hello everyone. I'm Dave and I've been lurking this list for some time, considering migrating a project from another genealogy program to Gramps. The project already has 140,000+ names. For the most part, I hope to be using Webapp on a Postgresql database (and I would like to contribute to the Webapp in time) but I'll want to be using Gramps application also, if possible. Is that out of the question for so many names? What's the largest project Gramps has ever handled, at any version? > On Mon, Oct 1, 2012 at 3:20 AM, Jérôme <rom...@ya...> wrote: > >> > For a Surname it takes around 20 seconds until the >> > result is displayed. I've nearly 28000 persons in my database. >> >> "Flat views are faster than Tree views" >> >> >> http://www.gramps-project.org/wiki/index.php?title=Tips_for_large_databases >> >> Try to rather to "display Surnames" via person list view! >> Surnames will not be grouped (parent node), but I know that it will be >> faster. >> >> Note, I got this problem with Place Tree View in the past (around 38 000 >> rows/entries) and I did not test Citations/Sources Tree View yet, which >> seems to use an other method (iteration, cursor) for displaying such >> grouped data. >> >> >> Jérôme >> >> Le 30/09/2012 15:53, Anton Huber a écrit : >> > Hello, >> > >> > searching in the database using person view is very slow on all my >> personal >> > computers and notebooks. For a Surname it takes around 20 seconds until >> the >> > result is displayed. I've nearly 28000 persons in my database. Is there >> a >> > way to make searching more comfortable for big database? >> > >> > Best regards, >> > >> > Anton >> > >> > >> > >> > >> ------------------------------------------------------------------------------ >> > Everyone hates slow websites. So do we. >> > Make your web apps faster with AppDynamics >> > Download AppDynamics Lite for free today: >> > http://ad.doubleclick.net/clk;258768047;13503038;j? >> > http://info.appdynamics.com/FreeJavaPerformanceDownload.html >> > >> > >> > >> > _______________________________________________ >> > Gramps-devel mailing list >> > Gra...@li... >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > >> >> >> >> ------------------------------------------------------------------------------ >> Got visibility? >> Most devs has no idea what their production app looks like. >> Find out how fast your code is with AppDynamics Lite. >> http://ad.doubleclick.net/clk;262219671;13503038;y? >> http://info.appdynamics.com/FreeJavaPerformanceDownload.html >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > |
From: Benny M. <ben...@gm...> - 2012-10-11 09:23:12
|
2012/10/11 Dave Burkholder <thi...@gm...> > Hello everyone. I'm Dave and I've been lurking this list for some time, > considering migrating a project from another genealogy program to Gramps. > The project already has 140,000+ names. > > For the most part, I hope to be using Webapp on a Postgresql database (and > I would like to contribute to the Webapp in time) but I'll want to be using > Gramps application also, if possible. Is that out of the question for so > many names? > Some things will be really slow I expect. Biggest problem is probably the import of so many names. Import happens as one database commit, but on importing so many names, you will go over the database page limit of one commit. That is a setting you can change however somewhere in the code. See http://gramps-project.org/wiki/index.php?title=Known_issues#GRAMPS_runs_out_of_locks Improving the import code to have it more performant for such a case would be a great addition :-) Once imported, I'm not sure the views will work good or not. We reworked the views to have them performant, but if that actually works on 140.000 is unknown. I'd be interested to know though. Latest results are here: http://www.gramps-project.org/wiki/index.php?title=GRAMPS_Performance You see that last test was with 3.3.0. on 120000+ people. Starting gramps up on the person listview was 15 sec. Switching to event view 1s (normally more events than you have people). Sorting event on date however was 30 sec, as obviously the entire table of dates must be sorted in memory. I suppose people would expect sorting to be slow in this case. Benny > What's the largest project Gramps has ever handled, at any version? > > > >> On Mon, Oct 1, 2012 at 3:20 AM, Jérôme <rom...@ya...> wrote: >> >>> > For a Surname it takes around 20 seconds until the >>> > result is displayed. I've nearly 28000 persons in my database. >>> >>> "Flat views are faster than Tree views" >>> >>> >>> http://www.gramps-project.org/wiki/index.php?title=Tips_for_large_databases >>> >>> Try to rather to "display Surnames" via person list view! >>> Surnames will not be grouped (parent node), but I know that it will be >>> faster. >>> >>> Note, I got this problem with Place Tree View in the past (around 38 000 >>> rows/entries) and I did not test Citations/Sources Tree View yet, which >>> seems to use an other method (iteration, cursor) for displaying such >>> grouped data. >>> >>> >>> Jérôme >>> >>> Le 30/09/2012 15:53, Anton Huber a écrit : >>> > Hello, >>> > >>> > searching in the database using person view is very slow on all my >>> personal >>> > computers and notebooks. For a Surname it takes around 20 seconds >>> until the >>> > result is displayed. I've nearly 28000 persons in my database. Is >>> there a >>> > way to make searching more comfortable for big database? >>> > >>> > Best regards, >>> > >>> > Anton >>> > >>> > >>> > >>> > >>> ------------------------------------------------------------------------------ >>> > Everyone hates slow websites. So do we. >>> > Make your web apps faster with AppDynamics >>> > Download AppDynamics Lite for free today: >>> > http://ad.doubleclick.net/clk;258768047;13503038;j? >>> > http://info.appdynamics.com/FreeJavaPerformanceDownload.html >>> > >>> > >>> > >>> > _______________________________________________ >>> > Gramps-devel mailing list >>> > Gra...@li... >>> > https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> > >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Got visibility? >>> Most devs has no idea what their production app looks like. >>> Find out how fast your code is with AppDynamics Lite. >>> http://ad.doubleclick.net/clk;262219671;13503038;y? >>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> >> > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: jerome <rom...@ya...> - 2012-10-11 09:34:26
|
You can also try the experimental 'gramps-connect'? http://gramps-project.org/wiki/index.php?title=Gramps-Connect --- En date de : Jeu 11.10.12, Benny Malengier <ben...@gm...> a écrit : De: Benny Malengier <ben...@gm...> Objet: Re: [Gramps-devel] slow database À: "Dave Burkholder" <thi...@gm...> Cc: Gra...@li... Date: Jeudi 11 octobre 2012, 11h23 2012/10/11 Dave Burkholder <thi...@gm...> Hello everyone. I'm Dave and I've been lurking this list for some time, considering migrating a project from another genealogy program to Gramps. The project already has 140,000+ names. For the most part, I hope to be using Webapp on a Postgresql database (and I would like to contribute to the Webapp in time) but I'll want to be using Gramps application also, if possible. Is that out of the question for so many names? Some things will be really slow I expect. Biggest problem is probably the import of so many names. Import happens as one database commit, but on importing so many names, you will go over the database page limit of one commit. That is a setting you can change however somewhere in the code. See http://gramps-project.org/wiki/index.php?title=Known_issues#GRAMPS_runs_out_of_locks Improving the import code to have it more performant for such a case would be a great addition :-) Once imported, I'm not sure the views will work good or not. We reworked the views to have them performant, but if that actually works on 140.000 is unknown. I'd be interested to know though. Latest results are here: http://www.gramps-project.org/wiki/index.php?title=GRAMPS_Performance You see that last test was with 3.3.0. on 120000+ people. Starting gramps up on the person listview was 15 sec. Switching to event view 1s (normally more events than you have people). Sorting event on date however was 30 sec, as obviously the entire table of dates must be sorted in memory. I suppose people would expect sorting to be slow in this case. Benny What's the largest project Gramps has ever handled, at any version? On Mon, Oct 1, 2012 at 3:20 AM, Jérôme <rom...@ya...> wrote: > For a Surname it takes around 20 seconds until the > result is displayed. I've nearly 28000 persons in my database. "Flat views are faster than Tree views" http://www.gramps-project.org/wiki/index.php?title=Tips_for_large_databases Try to rather to "display Surnames" via person list view! Surnames will not be grouped (parent node), but I know that it will be faster. Note, I got this problem with Place Tree View in the past (around 38 000 rows/entries) and I did not test Citations/Sources Tree View yet, which seems to use an other method (iteration, cursor) for displaying such grouped data. Jérôme Le 30/09/2012 15:53, Anton Huber a écrit : > Hello, > > searching in the database using person view is very slow on all my personal > computers and notebooks. For a Surname it takes around 20 seconds until the > result is displayed. I've nearly 28000 persons in my database. Is there a > way to make searching more comfortable for big database? > > Best regards, > > Anton > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel -----La pièce jointe associée suit----- ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev -----La pièce jointe associée suit----- _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Robert C. <rj...@ca...> - 2012-10-12 05:57:50
|
On Thu, 2012-10-11 at 11:23 +0200, Benny Malengier wrote: > > > 20121011 Dave Burkholder <thi...@gm...> > Hello everyone. I'm Dave and I've been lurking this list for > some time, considering migrating a project from another > genealogy program to Gramps. The project already has 140,000+ > names. > > For the most part, I hope to be using Webapp on a Postgresql > database (and I would like to contribute to the Webapp in > time) but I'll want to be using Gramps application also, if > possible. Is that out of the question for so many names? > > Some things will be really slow I expect. > Biggest problem is probably the import of so many names. Import > happens as one database commit, but on importing so many names, you > will go over the database page limit of one commit. > That is a setting you can change however somewhere in the code. See > http:gramps-project.orgwikiindex.php?title=Known_issues#GRAMPS_runs_out_of_locks > Improving the import code to have it more performant for such a case > would be a great addition :-) > > Once imported, I'm not sure the views will work good or not. We > reworked the views to have them performant, but if that actually works > on 140.000 is unknown. I'd be interested to know though. I work with a database of 141,000+names currently without difficulty (Gramps 3.3.1-1 on Fedora 16). Initial start is fairly slow though. First time to load each view is slow, but subsequent visits to views is almost immediate. Initial view load times - people 11 to 12 secs relationship abt 7 secs family 3 to 4 secs events 7 to 8 secs places 3 to 4 secs notes 11 to 12 secs ancestry view abt 1 sec or less Media abt 2 secs (although I only have about 1000 media in database) Repositories almost immediate sources about 1 sec - (time selecting a source varies according to number references for that source - my worst case is a civil registry which has about twice as many references as people in my database). Avoid leaving gramplets which do a lot a database work active - deep connections seems to be the worst case - as these slow everything down enormously. I do have the show relationship to home person enabled though and this does not seem to slow things appreciably. Inital import of the database from either gramps format or gedcom is tiresome though and can take a few hours. (would be really good if import could be sped up.) As stated above you will need to adjust the number of allowable locks. I current use: max_locks 300000 and max_objects 300000 I used to get away with half this, but not any more. The easiest way to do this is to create an empty database the add a file DB_CONFIG to the database directory before importing. Contents of DB_CONFIG #may want to fiddle with cachesize also #set_cachesize 0 200000000 2 set_lk_max_locks 300000 set_lk_max_objects 300000 Robert > > Latest results are here: > http:www.gramps-project.orgwikiindex.php?title=GRAMPS_Performance > You see that last test was with 3.3.0. on 120000+ people. Starting > gramps up on the person listview was 15 sec. Switching to event view > 1s (normally more events than you have people). Sorting event on date > however was 30 sec, as obviously the entire table of dates must be > sorted in memory. > I suppose people would expect sorting to be slow in this case. > > Benny > > > > What's the largest project Gramps has ever handled, at any > version? > > > On Mon, Oct 1, 2012 at 3:20 AM, Jérôme > <rom...@ya...> wrote: > > For a Surname it takes around 20 seconds > until the > > result is displayed. I've nearly 28000 > persons in my database. > > > "Flat views are faster than Tree views" > > http:www.gramps-project.orgwikiindex.php?title=Tips_for_large_databases > > Try to rather to "display Surnames" via person > list view! > Surnames will not be grouped (parent node), > but I know that it will be > faster. > > Note, I got this problem with Place Tree View > in the past (around 38 000 > rowsentries) and I did not test > CitationsSources Tree View yet, which > seems to use an other method (iteration, > cursor) for displaying such > grouped data. > > > Jérôme > > Le 30092012 15:53, Anton Huber a écrit : > > Hello, > > > > searching in the database using person view > is very slow on all my personal > > computers and notebooks. For a Surname it > takes around 20 seconds until the > > result is displayed. I've nearly 28000 > persons in my database. Is there a > > way to make searching more comfortable for > big database? > > > > Best regards, > > > > Anton > > > > > > > > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > > http:ad.doubleclick.netclk;258768047;13503038;j? > > > http:info.appdynamics.comFreeJavaPerformanceDownload.html > > > > > > > > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > > > https:lists.sourceforge.netlistslistinfogramps-devel > > > > > > ------------------------------------------------------------------------------ > Got visibility? > Most devs has no idea what their production > app looks like. > Find out how fast your code is with > AppDynamics Lite. > http:ad.doubleclick.netclk;262219671;13503038;y? > http:info.appdynamics.comFreeJavaPerformanceDownload.html > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https:lists.sourceforge.netlistslistinfogramps-devel > > > > > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New > Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, > and .NET app > Try New Relic at no cost today and get our sweet Data Nerd > shirt too! > http:p.sf.netsfunewrelic-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https:lists.sourceforge.netlistslistinfogramps-devel > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http:p.sf.netsfunewrelic-dev2dev > _______________________________________________ Gramps-devel mailing list Gra...@li... https:lists.sourceforge.netlistslistinfogramps-devel -- Robert Cawley Ph: +61 2 9543 1241 rj...@ca... rj...@we... rj...@op... |
From: Dave B. <thi...@gm...> - 2012-10-13 23:47:57
|
Thanks for your comments and suggestions, everyone. I was pretty sure Webapp wouldn't be the problem with the right database, but Gramps application performance was a question. The http://www.gramps-project.org/wiki/index.php?title=GRAMPS_Performance wiki page was great! I hadn't encountered that page before (gramps is well documented!) I used the db03 dataset on Gramps 3.4. My quad 925 AMD with 8 gig of ram imported the data in 50 minutes 40 seconds. Program performance after the import was satisfactory. This sets my mind at ease regarding Gramps suitability for my project. On Fri, Oct 12, 2012 at 1:27 AM, Robert Cawley <rj...@ca...> wrote: > On Thu, 2012-10-11 at 11:23 +0200, Benny Malengier wrote: > > > > > > 2012/10/11 Dave Burkholder <thi...@gm...> > > Hello everyone. I'm Dave and I've been lurking this list for > > some time, considering migrating a project from another > > genealogy program to Gramps. The project already has 140,000+ > > names. > > > > For the most part, I hope to be using Webapp on a Postgresql > > database (and I would like to contribute to the Webapp in > > time) but I'll want to be using Gramps application also, if > > possible. Is that out of the question for so many names? > > > > Some things will be really slow I expect. > > Biggest problem is probably the import of so many names. Import > > happens as one database commit, but on importing so many names, you > > will go over the database page limit of one commit. > > That is a setting you can change however somewhere in the code. See > > > http://gramps-project.org/wiki/index.php?title=Known_issues#GRAMPS_runs_out_of_locks > > Improving the import code to have it more performant for such a case > > would be a great addition :-) > > > > Once imported, I'm not sure the views will work good or not. We > > reworked the views to have them performant, but if that actually works > > on 140.000 is unknown. I'd be interested to know though. > > I work with a database of 141,000+names currently without difficulty > (Gramps 3.3.1-1 on Fedora 16). > Initial start is fairly slow though. > First time to load each view is slow, but subsequent visits to views is > almost immediate. > Initial view load times - > people 11 to 12 secs > relationship abt 7 secs > family 3 to 4 secs > events 7 to 8 secs > places 3 to 4 secs > notes 11 to 12 secs > ancestry view abt 1 sec or less > Media abt 2 secs (although I only have about 1000 media in database) > Repositories almost immediate > sources about 1 sec - (time selecting a source varies according to > number references for that source - my worst case is a civil registry > which has about twice as many references as people in my database). > > Avoid leaving gramplets which do a lot a database work active - deep > connections seems to be the worst case - as these slow everything down > enormously. > > I do have the show relationship to home person enabled though and this > does not seem to slow things appreciably. > > Inital import of the database from either gramps format or gedcom is > tiresome though and can take a few hours. (would be really good if > import could be sped up.) As stated above you will need to adjust the > number of allowable locks. I current use: > max_locks 300000 and > max_objects 300000 > I used to get away with half this, but not any more. > The easiest way to do this is to create an empty database the add a file > DB_CONFIG to the database directory before importing. > Contents of DB_CONFIG > > #may want to fiddle with cachesize also > #set_cachesize 0 200000000 2 > set_lk_max_locks 300000 > set_lk_max_objects 300000 > > Robert > > > > > > Latest results are here: > > http://www.gramps-project.org/wiki/index.php?title=GRAMPS_Performance > > You see that last test was with 3.3.0. on 120000+ people. Starting > > gramps up on the person listview was 15 sec. Switching to event view > > 1s (normally more events than you have people). Sorting event on date > > however was 30 sec, as obviously the entire table of dates must be > > sorted in memory. > > I suppose people would expect sorting to be slow in this case. > > > > Benny > > > > > > > > What's the largest project Gramps has ever handled, at any > > version? > > > > > > On Mon, Oct 1, 2012 at 3:20 AM, Jérôme > > <rom...@ya...> wrote: > > > For a Surname it takes around 20 seconds > > until the > > > result is displayed. I've nearly 28000 > > persons in my database. > > > > > > "Flat views are faster than Tree views" > > > > > http://www.gramps-project.org/wiki/index.php?title=Tips_for_large_databases > > > > Try to rather to "display Surnames" via person > > list view! > > Surnames will not be grouped (parent node), > > but I know that it will be > > faster. > > > > Note, I got this problem with Place Tree View > > in the past (around 38 000 > > rows/entries) and I did not test > > Citations/Sources Tree View yet, which > > seems to use an other method (iteration, > > cursor) for displaying such > > grouped data. > > > > > > Jérôme > > > > Le 30/09/2012 15:53, Anton Huber a écrit : > > > Hello, > > > > > > searching in the database using person view > > is very slow on all my personal > > > computers and notebooks. For a Surname it > > takes around 20 seconds until the > > > result is displayed. I've nearly 28000 > > persons in my database. Is there a > > > way to make searching more comfortable for > > big database? > > > > > > Best regards, > > > > > > Anton > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Everyone hates slow websites. So do we. > > > Make your web apps faster with AppDynamics > > > Download AppDynamics Lite for free today: > > > > > > http://ad.doubleclick.net/clk;258768047;13503038;j? > > > > > > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > > > > > > > > > > > > > > _______________________________________________ > > > Gramps-devel mailing list > > > Gra...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > > > > > > > > ------------------------------------------------------------------------------ > > Got visibility? > > Most devs has no idea what their production > > app looks like. > > Find out how fast your code is with > > AppDynamics Lite. > > > http://ad.doubleclick.net/clk;262219671;13503038;y? > > > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > Don't let slow site performance ruin your business. Deploy New > > Relic APM > > Deploy New Relic app performance management and know exactly > > what is happening inside your Ruby, Python, PHP, Java, > > and .NET app > > Try New Relic at no cost today and get our sweet Data Nerd > > shirt too! > > http://p.sf.net/sfu/newrelic-dev2dev > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > > > ------------------------------------------------------------------------------ > > Don't let slow site performance ruin your business. Deploy New Relic APM > > Deploy New Relic app performance management and know exactly > > what is happening inside your Ruby, Python, PHP, Java, and .NET app > > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > > http://p.sf.net/sfu/newrelic-dev2dev > > _______________________________________________ Gramps-devel mailing > list Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > -- > Robert Cawley > Ph: +61 2 9543 1241 > rj...@ca... > rj...@we... > rj...@op... > > > > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |