From: Martin E. <mar...@gm...> - 2008-08-31 01:20:07
|
I commented on this before, but now I have measured it. When I start out a Gramps session, it takes about 4 seconds of CPU work to add a new or edited user. (This is version 3.0.1-1 on a 1 GB Athlon XP 2000+ system with Fedora 8. My database has 2100+ people.) After I enter a number of new users and edits (maybe 20?), I see that it takes 25 seconds of CPU to add the new or edited data. When I quit and start a new session, everything is fine again. (I have tried database repair several times, and I killed my gramplets.) This major increase could be due to the overhead of maintaining the Undo stack. (Maybe.) Anyway, do other people see this, and is it a problem for you? It definitely slows me down. Even 4 seconds is more than it should be IMO. -- Martin Ewing, AA6E Branford, CT |
From: S. C. <ste...@gm...> - 2008-08-31 17:22:31
|
> Anyway, do other people see this, and is it a problem for you? It > definitely slows me down. Even 4 seconds is more than it should be IMO. No, I've never seen this. Adding a new person for me is "instantaneous". > When I start out a Gramps session, it takes about 4 seconds of CPU work to > add a new or edited user. (This is version 3.0.1-1 on a 1 GB Athlon XP > 2000+ system with Fedora 8. My database has 2100+ people.) My db has 2773 people. I'm using GRAMPS 3.0.1 under Ubuntu on a 2.4GHz computer, but my previous computer was around 1GHz and while the People view was slow to update as I would type characters to search, I don't ever remember adding a new person and having to wait. > After I enter a number of new users and edits (maybe 20?), I see that it > takes 25 seconds of CPU to add the new or edited data. When I quit and > start a new session, everything is fine again. (I have tried database > repair several times, and I killed my gramplets.) On some nights when I first created my db, I'd add several hundred people in a single session while working from my notes and books. I never had to quit GRAMPS to get things to speed up. This was back in the late 2.2.x days, so it may not apply to you if you believe the problem is specific to 3.x. > This major increase could be due to the overhead of maintaining the Undo > stack. (Maybe.) I'd argue the problem is something specific to your setup, since I've never heard of anyone else explain how they have to quit GRAMPS after 20 edits to get things to go faster. Stéphane |
From: Martin E. <mar...@gm...> - 2008-08-31 17:40:49
|
On Sun, Aug 31, 2008 at 1:22 PM, Stéphane Charette < ste...@gm...> wrote: > > Anyway, do other people see this, and is it a problem for you? It > > definitely slows me down. Even 4 seconds is more than it should be IMO. > > No, I've never seen this. Adding a new person for me is "instantaneous". > > > When I start out a Gramps session, it takes about 4 seconds of CPU work > to > > add a new or edited user. (This is version 3.0.1-1 on a 1 GB Athlon XP > > 2000+ system with Fedora 8. My database has 2100+ people.) > > My db has 2773 people. I'm using GRAMPS 3.0.1 under Ubuntu on a > 2.4GHz computer, but my previous computer was around 1GHz and while > the People view was slow to update as I would type characters to > search, I don't ever remember adding a new person and having to wait. > > > After I enter a number of new users and edits (maybe 20?), I see that it > > takes 25 seconds of CPU to add the new or edited data. When I quit and > > start a new session, everything is fine again. (I have tried database > > repair several times, and I killed my gramplets.) > > On some nights when I first created my db, I'd add several hundred > people in a single session while working from my notes and books. I > never had to quit GRAMPS to get things to speed up. This was back in > the late 2.2.x days, so it may not apply to you if you believe the > problem is specific to 3.x. > > > This major increase could be due to the overhead of maintaining the Undo > > stack. (Maybe.) > > I'd argue the problem is something specific to your setup, since I've > never heard of anyone else explain how they have to quit GRAMPS after > 20 edits to get things to go faster. > > Stéphane > Thanks for the reassurance (? ;-). Now, of course, I go back and try simple add/delete operations, and there is no problem! (It is very odd, since before I rebooted my computer this morning, updates were taking ~4 seconds, but now they are much quicker.) It must be something associated with a long and complex session - memory leak? I will try to check "Undo history..." to see how the problem develops. Other ideas would be welcome. -- Martin Ewing, AA6E Branford, CT |
From: Alvaro H. <alv...@al...> - 2008-09-01 02:37:36
|
Stéphane Charette escribió: > > This major increase could be due to the overhead of maintaining the Undo > > stack. (Maybe.) > > I'd argue the problem is something specific to your setup, since I've > never heard of anyone else explain how they have to quit GRAMPS after > 20 edits to get things to go faster. It does happen to me too, and I remember someone else reporting a similar thing not long ago. Can anyone suggest a Python profiler? -- Alvaro Herrera http://www.amazon.com/gp/registry/3BP7BYG9PUGI8 Are you not unsure you want to delete Firefox? [Not unsure] [Not not unsure] [Cancel] http://smylers.hates-software.com/2008/01/03/566e45b2.html |
From: Algis K. <aka...@pc...> - 2008-09-02 00:20:17
|
On Mon, 1 Sep 2008 12:37:37 Alvaro Herrera wrote: > Stéphane Charette escribió: > > > This major increase could be due to the overhead of maintaining the > > > Undo stack. (Maybe.) > > > > I'd argue the problem is something specific to your setup, since I've > > never heard of anyone else explain how they have to quit GRAMPS after > > 20 edits to get things to go faster. > > It does happen to me too, and I remember someone else reporting a > similar thing not long ago. > > Can anyone suggest a Python profiler? Extract from wikipedia: ******************** Python: Python profiling includes the profile module, hotshot (which is call-graph based), and using the 'sys.setprofile()' module to trap events like c_{call,return,exception}, python_{call,return,exception}. ******************** My 2c worth... OldAl. -- Dr Algis Kabaila (PhD Eng) http://akabaila.pcug.org.au/StructuralAnalysis/ ------------------------------------------------ |
From: Benny M. <ben...@gm...> - 2008-09-01 07:16:10
|
There is built in profiling: http://docs.python.org/lib/profile.html You will find some hooks in the GRAMPS code to set up profiling. It is a long time I did it, perhaps somebody else can give some pointers... Just grep on profile in the source code, you might stumble on it. In this case, profiling would be the best way to find where the problem is. You need the source code obviously: http://www.gramps-project.org/wiki/index.php?title=Getting_Started_with_GRAMPS_development Benny 2008/9/1 Alvaro Herrera <alv...@al...> > Stéphane Charette escribió: > > > > This major increase could be due to the overhead of maintaining the > Undo > > > stack. (Maybe.) > > > > I'd argue the problem is something specific to your setup, since I've > > never heard of anyone else explain how they have to quit GRAMPS after > > 20 edits to get things to go faster. > > It does happen to me too, and I remember someone else reporting a > similar thing not long ago. > > Can anyone suggest a Python profiler? > > -- > Alvaro Herrera > http://www.amazon.com/gp/registry/3BP7BYG9PUGI8 > Are you not unsure you want to delete Firefox? > [Not unsure] [Not not unsure] [Cancel] > > http://smylers.hates-software.com/2008/01/03/566e45b2.html > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > |
From: Benny M. <ben...@gm...> - 2008-09-01 07:32:11
|
As a side idea, if you open the process viewer (eg top), is GRAMPS the only process taking up the CPU? Eg., ifyou people run something like beagle or strigi or whatever indexer, it could interact with GRAMPS writing activity. (in that case it might be interesting to make sure the ~/.gramps directory is not indexed) Benny 2008/9/1 Benny Malengier <ben...@gm...> > There is built in profiling: > http://docs.python.org/lib/profile.html > > You will find some hooks in the GRAMPS code to set up profiling. It is a > long time I did it, perhaps somebody else can give some pointers... > Just grep on profile in the source code, you might stumble on it. > > In this case, profiling would be the best way to find where the problem is. > You need the source code obviously: > http://www.gramps-project.org/wiki/index.php?title=Getting_Started_with_GRAMPS_development > > Benny > > 2008/9/1 Alvaro Herrera <alv...@al...> > > Stéphane Charette escribió: >> >> > > This major increase could be due to the overhead of maintaining the >> Undo >> > > stack. (Maybe.) >> > >> > I'd argue the problem is something specific to your setup, since I've >> > never heard of anyone else explain how they have to quit GRAMPS after >> > 20 edits to get things to go faster. >> >> It does happen to me too, and I remember someone else reporting a >> similar thing not long ago. >> >> Can anyone suggest a Python profiler? >> >> -- >> Alvaro Herrera >> http://www.amazon.com/gp/registry/3BP7BYG9PUGI8 >> Are you not unsure you want to delete Firefox? >> [Not unsure] [Not not unsure] [Cancel] >> >> http://smylers.hates-software.com/2008/01/03/566e45b2.html >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Gramps-users mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-users >> > > |