From: Gerald B. <ger...@gm...> - 2009-06-24 16:26:15
|
So... I'm playing around trying to speed up how people view works. In the method build_tree in PeopleView.py, I wrapped just one statement with commands to disconnect the tree from the model and reconnect it after: self.tree.set_model(None) # disconnect model from tree self.build_columns() self.tree.set_model(self.model) # reconnect model to tree This one change seems to have restored normal performance. To test this, I first added a "print ..." to thefirst_child() method in _PeopleModel.py, loaded up the small sample.ged in svn, then changed one name from Smith to Smithx. Before the little patch above, changing the name caused about 5600 calls to first_child() (!). Retesting with this little patch reduced the calls to just 70 or so. I call that an improvement! So, is this the right thing to do (and the right place to do it?) If so, I think that it is worth patching in branch and trunk. If not, where should this change happen? On Wed, Jun 24, 2009 at 7:38 AM, Benny Malengier<ben...@gm...> wrote: > info, > > after googling a bit: > http://tecnocode.co.uk/2007/10/02/adding-to-a-gtktreeview-as-you-scroll/ > read what hergert says. I found this blog of him > http://audidude.com/blog/?p=9 > where he says what functions are most called, so what benefits most > of optimization: > Code for models on sqlite and bdb: > http://github.com/chergert/custom-gtk-widgets/tree/master > > We can learn some things from that propably. But we need more complex > things due to the sorting. > > Note that this guy just released a general plugin system for GTK apps, > and the marina app he works on stores rss in bsddb > > Benny > > 2009/6/24 Gerald Britton <ger...@gm...>: >> I haven't lived with this code long enough to fully grasp it. On the >> gtk list I got a suggestion to disconnect the model much as you >> describe but I am not sure where to do that. >> >> The confusing thing is that treeview eventually stops calling >> iter-next. I'd like to know what makes it stop. >> >> I see that there are ref and unref methods available for very large >> trees. Maybe something we can use. >> >> >> >> On 6/24/09, Benny Malengier <ben...@gm...> wrote: >>> My ignorance showed in the previous post. >>> Row inserted must be called to notify the view if you create your own >>> treemodel. >>> The idea behind this method as indicated on >>> http://www.pygtk.org/pygtk2tutorial/sec-GenericTreeModel.html is >>> avoiding recreating the model (which is the alternative), GRAMPS in >>> essence rebuilds the model anyway instead of updating, then calls the >>> row_inserted on the new lines. >>> >>> 2009/6/24 Benny Malengier <ben...@gm...>: >>>> Added devel list so discussion is documented >>>> comments below >>>> >>>> 2009/6/24 Gerald Britton <ger...@gm...>: >>>>> Interesting. This _does_ look worthwhile! I have never used the >>>>> bisect module, but it seems simple enough. Have you done any timings? >>>>> Does it give us some time back? >>>>> >>>>> The code around line 210 could take advantage of my latest changes to >>>>> grampscursor, I think. Then you could write: >>>>> ... >>>>> with self.gen_cursor() as cursor: # use cursor as a context manager >>>>> for key, data in cursor: # use iterator method of cursor >>>>> bisect.insort_left(self.sort_data, >>>>> (locale.strxfrm(self.sort_func(data)), >>>>> key)) >>>>> ... >>>>> and not have to do calls to cursor.next() and cursor.close() >>>>> >>>>> You're certainly right to replace cmp=locale.strcoll with >>>>> key=locale.strxfrm for sorting applications. I've been planning to go >>>>> through our code base and make that change wherever I can, not only >>>>> because it's faster but also because cmp= is gone in Python 3.x >>>>> >>>>> You can make this bit near 228 simpler: >>>>> >>>>> + dlist = [h[1] for h in self.sort_keys()\ >>>>> + if self.search.match(h[1],self.db) and \ >>>>> + h[1] not in self.skip and h[1] != ignore] >>>>> >>>>> since you can write: >>>>> >>>>> + dlist = [h for h, h_ in self.sort_keys()\ >>>>> + if self.search.match(h,self.db) and \ >>>>> + h not in self.skip and h != ignore] >>>>> >>>>> if self.sort_keys() yields tuples. You just don't use the h_ but the >>>>> expression is a little neater I think (though not any faster). >>>>> >>>>> Same thing around 248. >>>>> >>>>> On the whole its a pity we have to use lists. Iterators would be >>>>> nicer but when you have to sort stuff there's not much choice. >>>>> >>>>> I like the way you're thinking here and I'm really interested to know >>>>> how much we will benefit from the bisect module. >>>> >>>> ok, I'll add a fast timing to see what it does. It should be slower in >>>> small databases where speed is no issue anyway, and faster for large >>>> databases. >>>> >>>>> >>>>> On PersonView, I'm still trying to work out what happens after I >>>>> change some data. Using the little .ged sample (just 43 people), >>>>> TreeView makes just 43 or so calls to iter_next when building the tree >>>>> view initially. After I change a surname, it makes almost 24,000 >>>>> (yes, that's twenty-four thousand!) calls to iter_next to rebuild the >>>>> tree view. This is obviously not right. What I'm trying to work out >>>>> is what TreeView is looking for to know that it has finished >>>>> rebuilding the tree. It stops eventually, but should stop 23,967 >>>>> calls earlier, I believe. >>>> >>>> My guess would be the model changes, and the tree tries to update as >>>> the model is changing. This is complicated code though, I'm not >>>> acquainted with it. >>>> Note that if I here add a print statement to has_child in the model, I >>>> get normal expected behaviour.... Can you add a patch with the >>>> profiling code in? >>>> >>>> So, I see the add_person signal catched and in person_added, you then see >>>> self.model.rebuild_data(self.model.current_filter) >>>> without the model being deactivated from the treeview first. Strange >>>> thing is that then nevertheless the row_inserted method is called >>>> further on. Should I code this myself my idea would be to disconnect >>>> the model, redo it (or better, as in the optimization, just add the >>>> new people in the correct place of the model without rebuild), and >>>> connect the model again. >>>> It is also strange that this rebuild is inside a loop, once the >>>> database has been updated, the rebuild should just find the correct >>>> data. >>>> >>>> So the reasoning in GRAMPS went like this in the past: TreeStore was >>>> too inefficient, as it holds all data, too use, so Don/Alex had to >>>> roll their own Treemodel, for PeopleView that is >>>> PeopleModel(gtk.GenericTreeModel) >>>> The idea here is that we don't store the data outside the database for >>>> memory reasons, but instead only store a (handle, sortstring) in >>>> memory, obtaining the data from the database the moment it is needed. >>>> This idea is today still valid I believe. >>>> A treeview works based on paths (unique key) and nodes (storage index >>>> in the tree), and one needs to be able to determine one from the other >>>> quickly, which is what the NodeTreeMap class is for. >>>> As you see so many database hits, something is going bad. Strange that >>>> a print here does not indicate here many calls to has_child in the >>>> NodeTreeMap >>>> >>>> Anyway, I want to rewrite that code for 3.2 as I would like to have >>>> the code more organized and understandable, as well as create more >>>> flexibility: change from grouped view to flat view in several views, >>>> sort on columns, ... . I think this should be possible without too >>>> much penalty hit if only keys are in memory via the array module, and >>>> utilizing the strength of bisect to add and delete in that memory >>>> without rebuilding the entire model. >>>> Knowing what the bottleneck is now would be a big start though. >>>> >>>> Benny >>>>> >>>>> On Tue, Jun 23, 2009 at 5:49 PM, Benny >>>>> Malengier<ben...@gm...> wrote: >>>>>> Gerald, offlist, >>>>>> >>>>>> in attachment some changes to _BaseModel.py, used by all views except >>>>>> person view. >>>>>> I attempt some code optimizations. I'd like to remove the sort after >>>>>> an insert of an item, as well as some double list assignments. >>>>>> >>>>>> I would like to work in the views to make them more versatile, hence >>>>>> these tries. >>>>>> >>>>>> What do you think? Worthwhile? >>>>>> >>>>>> Benny >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Gerald Britton >>>>> >>>> >>> >> >> -- >> Sent from my mobile device >> >> Gerald Britton >> > -- Gerald Britton |
From: Benny M. <ben...@gm...> - 2009-06-24 19:50:49
|
2009/6/24 Gerald Britton <ger...@gm...>: > So... I'm playing around trying to speed up how people view works. In > the method build_tree in PeopleView.py, I wrapped just one statement > with commands to disconnect the tree from the model and reconnect it > after: > > self.tree.set_model(None) # disconnect model from tree > self.build_columns() > self.tree.set_model(self.model) # reconnect model to tree > > This one change seems to have restored normal performance. To test > this, I first added a "print ..." to thefirst_child() method in > _PeopleModel.py, loaded up the small sample.ged in svn, then changed > one name from Smith to Smithx. Before the little patch above, > changing the name caused about 5600 calls to first_child() (!). > Retesting with this little patch reduced the calls to just 70 or so. > I call that an improvement! First, if on my box I add this print statement on the example database (2090 people), I obtain one print of first_child (I suppose you added it in NodeTreeMap) on load. Then, if I move my mouse over entries, it prints one line per row. Changing a name and save causes some 5 to 10 prints depending on how much of the treeview becomes visible. Conclusion: this speeddown you have is some kind of regression. One would think from above too many X events or so are triggering change as the edit dialog closes. That is, GTK is in different threads, in one thread we are rebuilding the model, in the other thread X events need to be processed to redraw the TreeView, causing calls to the iter methods. Changing the columns while that happens probably does not help either. What you do to remove the model then reattach, is quite standard, so I see no reason to not do that as a solution now in 31 and trunk. It might cause a slowdown for the people who don't have this problem, who knows? I believe for trunk we must work on a way that does not need the columns to be rebuild on a simple change of names. Unattaching a model and reattaching will probably cause all the visible treeview to be reconstructed on screen, as opposed to only the part that is needed. I'm no expert, I wouldn't know. Instead of the change you know mention, I believe you can just wait with attaching the model in build_tree. So, in the start of that method, set the model to none, perhaps do a del on the present model if not None, so it really goes away as soon as possible, then only after building the columns, attach the model. If you do that patch now, and we wait some time, it should be used quite a bit before next release. Benny |
From: Gerald B. <ger...@gm...> - 2009-06-24 20:02:24
|
Interesting that your results are so different. I did a similar test with the large sample db (same one as you I think). I changed one "garner" to "garnerx". I got: 1214 lines printed before I changed the name 3002 lines printed after I changed the name Still way too much work but a big improvement on the 10's of thousands I was seeing. I sure can't understand why you get one line where I get over 1200, though. Here's my modified method with the print statements: def first_child(self, node): if node is None: print "None,", self.top_path2iter[0] return self.top_path2iter[0] else: print node, self.path2iter.get((node, 0)) return self.path2iter.get((node, 0)) On Wed, Jun 24, 2009 at 3:50 PM, Benny Malengier<ben...@gm...> wrote: > 2009/6/24 Gerald Britton <ger...@gm...>: >> So... I'm playing around trying to speed up how people view works. In >> the method build_tree in PeopleView.py, I wrapped just one statement >> with commands to disconnect the tree from the model and reconnect it >> after: >> >> self.tree.set_model(None) # disconnect model from tree >> self.build_columns() >> self.tree.set_model(self.model) # reconnect model to tree >> >> This one change seems to have restored normal performance. To test >> this, I first added a "print ..." to thefirst_child() method in >> _PeopleModel.py, loaded up the small sample.ged in svn, then changed >> one name from Smith to Smithx. Before the little patch above, >> changing the name caused about 5600 calls to first_child() (!). >> Retesting with this little patch reduced the calls to just 70 or so. >> I call that an improvement! > > First, if on my box I add this print statement on the example database > (2090 people), I obtain one print of first_child (I suppose you added > it in NodeTreeMap) on load. Then, if I move my mouse over entries, it > prints one line per row. Changing a name and save causes some 5 to 10 > prints depending on how much of the treeview becomes visible. > > Conclusion: this speeddown you have is some kind of regression. One > would think from above too many X events or so are triggering change > as the edit dialog closes. That is, GTK is in different threads, in > one thread we are rebuilding the model, in the other thread X events > need to be processed to redraw the TreeView, causing calls to the iter > methods. Changing the columns while that happens probably does not > help either. > > What you do to remove the model then reattach, is quite standard, so I > see no reason to not do that as a solution now in 31 and trunk. It > might cause a slowdown for the people who don't have this problem, who > knows? > I believe for trunk we must work on a way that does not need the > columns to be rebuild on a simple change of names. Unattaching a model > and reattaching will probably cause all the visible treeview to be > reconstructed on screen, as opposed to only the part that is needed. > I'm no expert, I wouldn't know. > > Instead of the change you know mention, I believe you can just wait > with attaching the model in build_tree. So, in the start of that > method, set the model to none, perhaps do a del on the present model > if not None, so it really goes away as soon as possible, then only > after building the columns, attach the model. > > If you do that patch now, and we wait some time, it should be used > quite a bit before next release. > > Benny > -- Gerald Britton |
From: Gerald B. <ger...@gm...> - 2009-06-24 20:28:52
|
Committed rev 12703. Couldn't defer attaching the model due to some other things in this method that depend on it. Keeps the change local for now. On Wed, Jun 24, 2009 at 4:01 PM, Gerald Britton<ger...@gm...> wrote: > Interesting that your results are so different. I did a similar test > with the large sample db (same one as you I think). I changed one > "garner" to "garnerx". I got: > > 1214 lines printed before I changed the name > 3002 lines printed after I changed the name > > Still way too much work but a big improvement on the 10's of thousands > I was seeing. I sure can't understand why you get one line where I > get over 1200, though. > > Here's my modified method with the print statements: > > def first_child(self, node): > if node is None: > print "None,", self.top_path2iter[0] > return self.top_path2iter[0] > else: > print node, self.path2iter.get((node, 0)) > return self.path2iter.get((node, 0)) > > On Wed, Jun 24, 2009 at 3:50 PM, Benny > Malengier<ben...@gm...> wrote: >> 2009/6/24 Gerald Britton <ger...@gm...>: >>> So... I'm playing around trying to speed up how people view works. In >>> the method build_tree in PeopleView.py, I wrapped just one statement >>> with commands to disconnect the tree from the model and reconnect it >>> after: >>> >>> self.tree.set_model(None) # disconnect model from tree >>> self.build_columns() >>> self.tree.set_model(self.model) # reconnect model to tree >>> >>> This one change seems to have restored normal performance. To test >>> this, I first added a "print ..." to thefirst_child() method in >>> _PeopleModel.py, loaded up the small sample.ged in svn, then changed >>> one name from Smith to Smithx. Before the little patch above, >>> changing the name caused about 5600 calls to first_child() (!). >>> Retesting with this little patch reduced the calls to just 70 or so. >>> I call that an improvement! >> >> First, if on my box I add this print statement on the example database >> (2090 people), I obtain one print of first_child (I suppose you added >> it in NodeTreeMap) on load. Then, if I move my mouse over entries, it >> prints one line per row. Changing a name and save causes some 5 to 10 >> prints depending on how much of the treeview becomes visible. >> >> Conclusion: this speeddown you have is some kind of regression. One >> would think from above too many X events or so are triggering change >> as the edit dialog closes. That is, GTK is in different threads, in >> one thread we are rebuilding the model, in the other thread X events >> need to be processed to redraw the TreeView, causing calls to the iter >> methods. Changing the columns while that happens probably does not >> help either. >> >> What you do to remove the model then reattach, is quite standard, so I >> see no reason to not do that as a solution now in 31 and trunk. It >> might cause a slowdown for the people who don't have this problem, who >> knows? >> I believe for trunk we must work on a way that does not need the >> columns to be rebuild on a simple change of names. Unattaching a model >> and reattaching will probably cause all the visible treeview to be >> reconstructed on screen, as opposed to only the part that is needed. >> I'm no expert, I wouldn't know. >> >> Instead of the change you know mention, I believe you can just wait >> with attaching the model in build_tree. So, in the start of that >> method, set the model to none, perhaps do a del on the present model >> if not None, so it really goes away as soon as possible, then only >> after building the columns, attach the model. >> >> If you do that patch now, and we wait some time, it should be used >> quite a bit before next release. >> >> Benny >> > > > > -- > Gerald Britton > -- Gerald Britton |
From: Benny M. <ben...@gm...> - 2009-06-25 08:01:22
|
The only thing I can think of is that in your case the gtk_main loop is causing some asynchrous calls in your box. If you want to investigate further, I would suggest to add the gdk debug version, and then run it with debug option events to see what is being passed from X. See http://euler.aero.iitb.ac.in/docs/Graphics/GTK-2.x/gtk/gtk-running.html#GDK-Debug-Options Benny 2009/6/24 Gerald Britton <ger...@gm...>: > Committed rev 12703. Couldn't defer attaching the model due to some > other things in this method that depend on it. Keeps the change local > for now. > > On Wed, Jun 24, 2009 at 4:01 PM, Gerald Britton<ger...@gm...> wrote: >> Interesting that your results are so different. I did a similar test >> with the large sample db (same one as you I think). I changed one >> "garner" to "garnerx". I got: >> >> 1214 lines printed before I changed the name >> 3002 lines printed after I changed the name >> >> Still way too much work but a big improvement on the 10's of thousands >> I was seeing. I sure can't understand why you get one line where I >> get over 1200, though. >> >> Here's my modified method with the print statements: >> >> def first_child(self, node): >> if node is None: >> print "None,", self.top_path2iter[0] >> return self.top_path2iter[0] >> else: >> print node, self.path2iter.get((node, 0)) >> return self.path2iter.get((node, 0)) >> >> On Wed, Jun 24, 2009 at 3:50 PM, Benny >> Malengier<ben...@gm...> wrote: >>> 2009/6/24 Gerald Britton <ger...@gm...>: >>>> So... I'm playing around trying to speed up how people view works. In >>>> the method build_tree in PeopleView.py, I wrapped just one statement >>>> with commands to disconnect the tree from the model and reconnect it >>>> after: >>>> >>>> self.tree.set_model(None) # disconnect model from tree >>>> self.build_columns() >>>> self.tree.set_model(self.model) # reconnect model to tree >>>> >>>> This one change seems to have restored normal performance. To test >>>> this, I first added a "print ..." to thefirst_child() method in >>>> _PeopleModel.py, loaded up the small sample.ged in svn, then changed >>>> one name from Smith to Smithx. Before the little patch above, >>>> changing the name caused about 5600 calls to first_child() (!). >>>> Retesting with this little patch reduced the calls to just 70 or so. >>>> I call that an improvement! >>> >>> First, if on my box I add this print statement on the example database >>> (2090 people), I obtain one print of first_child (I suppose you added >>> it in NodeTreeMap) on load. Then, if I move my mouse over entries, it >>> prints one line per row. Changing a name and save causes some 5 to 10 >>> prints depending on how much of the treeview becomes visible. >>> >>> Conclusion: this speeddown you have is some kind of regression. One >>> would think from above too many X events or so are triggering change >>> as the edit dialog closes. That is, GTK is in different threads, in >>> one thread we are rebuilding the model, in the other thread X events >>> need to be processed to redraw the TreeView, causing calls to the iter >>> methods. Changing the columns while that happens probably does not >>> help either. >>> >>> What you do to remove the model then reattach, is quite standard, so I >>> see no reason to not do that as a solution now in 31 and trunk. It >>> might cause a slowdown for the people who don't have this problem, who >>> knows? >>> I believe for trunk we must work on a way that does not need the >>> columns to be rebuild on a simple change of names. Unattaching a model >>> and reattaching will probably cause all the visible treeview to be >>> reconstructed on screen, as opposed to only the part that is needed. >>> I'm no expert, I wouldn't know. >>> >>> Instead of the change you know mention, I believe you can just wait >>> with attaching the model in build_tree. So, in the start of that >>> method, set the model to none, perhaps do a del on the present model >>> if not None, so it really goes away as soon as possible, then only >>> after building the columns, attach the model. >>> >>> If you do that patch now, and we wait some time, it should be used >>> quite a bit before next release. >>> >>> Benny >>> >> >> >> >> -- >> Gerald Britton >> > > > > -- > Gerald Britton > |
From: Gerald B. <ger...@gm...> - 2009-06-25 14:24:46
|
You could be right and I will check out that debugger. In the meantime, here's something interesting. With those print statements in place, I started gramps: jerryb1@ubuntu:~/gramps32$ python src/gramps.py > /tmp/out error: duplicate REP tables used Failure loading aff file /usr/share/myspell/dicts/en_ZA.aff ^Z[1] Done python src/gramps.py > /tmp/out [2]+ Stopped python src/gramps.py > /tmp/out jerryb1@ubuntu:~/gramps32$ bg [2]+ python src/gramps.py > /tmp/out & jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out 0 /tmp/out Then, I opened People View and clicked on person id I44 (Lewis Anderson Garner) jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out 3597 /tmp/out Note that that is about 1.75 times the number of people in the db. Then I clicked on the person above I44 who is I1105 (Lewis Garner) jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out 5397 /tmp/out 1800 calls to first_child! Then I clicked back on i44 jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out 6596 /tmp/out Another 1200 calls. Back to I2205 jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out 7797 /tmp/out Another 1200 calls. Finally I exited gramps jerryb1@ubuntu:~/gramps32$ I know that this is unscientific, but to me it indicates that there is something amiss. I, of course, am generating the X events by clicking one row up or one row down. I can't see why it is necessary to run through so many people every time this happens, though. On Thu, Jun 25, 2009 at 4:01 AM, Benny Malengier<ben...@gm...> wrote: > The only thing I can think of is that in your case the gtk_main loop > is causing some asynchrous calls in your box. > If you want to investigate further, I would suggest to add the gdk > debug version, and then run it with debug option events to see what is > being passed from X. > See http://euler.aero.iitb.ac.in/docs/Graphics/GTK-2.x/gtk/gtk-running.html#GDK-Debug-Options > > Benny > > 2009/6/24 Gerald Britton <ger...@gm...>: >> Committed rev 12703. Couldn't defer attaching the model due to some >> other things in this method that depend on it. Keeps the change local >> for now. >> >> On Wed, Jun 24, 2009 at 4:01 PM, Gerald Britton<ger...@gm...> wrote: >>> Interesting that your results are so different. I did a similar test >>> with the large sample db (same one as you I think). I changed one >>> "garner" to "garnerx". I got: >>> >>> 1214 lines printed before I changed the name >>> 3002 lines printed after I changed the name >>> >>> Still way too much work but a big improvement on the 10's of thousands >>> I was seeing. I sure can't understand why you get one line where I >>> get over 1200, though. >>> >>> Here's my modified method with the print statements: >>> >>> def first_child(self, node): >>> if node is None: >>> print "None,", self.top_path2iter[0] >>> return self.top_path2iter[0] >>> else: >>> print node, self.path2iter.get((node, 0)) >>> return self.path2iter.get((node, 0)) >>> >>> On Wed, Jun 24, 2009 at 3:50 PM, Benny >>> Malengier<ben...@gm...> wrote: >>>> 2009/6/24 Gerald Britton <ger...@gm...>: >>>>> So... I'm playing around trying to speed up how people view works. In >>>>> the method build_tree in PeopleView.py, I wrapped just one statement >>>>> with commands to disconnect the tree from the model and reconnect it >>>>> after: >>>>> >>>>> self.tree.set_model(None) # disconnect model from tree >>>>> self.build_columns() >>>>> self.tree.set_model(self.model) # reconnect model to tree >>>>> >>>>> This one change seems to have restored normal performance. To test >>>>> this, I first added a "print ..." to thefirst_child() method in >>>>> _PeopleModel.py, loaded up the small sample.ged in svn, then changed >>>>> one name from Smith to Smithx. Before the little patch above, >>>>> changing the name caused about 5600 calls to first_child() (!). >>>>> Retesting with this little patch reduced the calls to just 70 or so. >>>>> I call that an improvement! >>>> >>>> First, if on my box I add this print statement on the example database >>>> (2090 people), I obtain one print of first_child (I suppose you added >>>> it in NodeTreeMap) on load. Then, if I move my mouse over entries, it >>>> prints one line per row. Changing a name and save causes some 5 to 10 >>>> prints depending on how much of the treeview becomes visible. >>>> >>>> Conclusion: this speeddown you have is some kind of regression. One >>>> would think from above too many X events or so are triggering change >>>> as the edit dialog closes. That is, GTK is in different threads, in >>>> one thread we are rebuilding the model, in the other thread X events >>>> need to be processed to redraw the TreeView, causing calls to the iter >>>> methods. Changing the columns while that happens probably does not >>>> help either. >>>> >>>> What you do to remove the model then reattach, is quite standard, so I >>>> see no reason to not do that as a solution now in 31 and trunk. It >>>> might cause a slowdown for the people who don't have this problem, who >>>> knows? >>>> I believe for trunk we must work on a way that does not need the >>>> columns to be rebuild on a simple change of names. Unattaching a model >>>> and reattaching will probably cause all the visible treeview to be >>>> reconstructed on screen, as opposed to only the part that is needed. >>>> I'm no expert, I wouldn't know. >>>> >>>> Instead of the change you know mention, I believe you can just wait >>>> with attaching the model in build_tree. So, in the start of that >>>> method, set the model to none, perhaps do a del on the present model >>>> if not None, so it really goes away as soon as possible, then only >>>> after building the columns, attach the model. >>>> >>>> If you do that patch now, and we wait some time, it should be used >>>> quite a bit before next release. >>>> >>>> Benny >>>> >>> >>> >>> >>> -- >>> Gerald Britton >>> >> >> >> >> -- >> Gerald Britton >> > -- Gerald Britton |
From: Benny M. <ben...@gm...> - 2009-06-25 14:52:20
|
2009/6/25 Gerald Britton <ger...@gm...>: > You could be right and I will check out that debugger. In the > meantime, here's something interesting. With those print statements > in place, I started gramps: > > jerryb1@ubuntu:~/gramps32$ python src/gramps.py > /tmp/out > error: duplicate REP tables used > Failure loading aff file /usr/share/myspell/dicts/en_ZA.aff > ^Z[1] Done python src/gramps.py > /tmp/out > > [2]+ Stopped python src/gramps.py > /tmp/out > jerryb1@ubuntu:~/gramps32$ bg > [2]+ python src/gramps.py > /tmp/out & > jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out > 0 /tmp/out > > Then, I opened People View and clicked on person id I44 (Lewis Anderson Garner) > > jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out > 3597 /tmp/out > > Note that that is about 1.75 times the number of people in the db. > Then I clicked on the person above I44 who is I1105 (Lewis Garner) > > jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out > 5397 /tmp/out > > 1800 calls to first_child! Then I clicked back on i44 > > jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out > 6596 /tmp/out > > Another 1200 calls. Back to I2205 > > jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out > 7797 /tmp/out > > Another 1200 calls. Finally I exited gramps > jerryb1@ubuntu:~/gramps32$ > > I know that this is unscientific, but to me it indicates that there is > something amiss. I, of course, am generating the X events by clicking > one row up or one row down. I can't see why it is necessary to run > through so many people every time this happens, though. When you click, the selection color changes, and the treeview is redrawn, on mouseover it might be needed to show help, so he redraws. Every time he probably goes back to the model to see if there was a change, and if so asks a number up and down of the visibile area to see if the positioning remains the same (like scrollbars). If the drawing is implemented efficiently, they would however notice no row_inserted, .... signal was recieved, so nothing changed, and they need not request so many data, only the row that is left and the row that is put in selection as those are redrawn. I'll check at home on my box how many prints I have, but I expect I will only have 1 or 2. As we have had problems in the past, I hope you have no assistive technologies (read atk) installed? Benny |
From: Gerald B. <ger...@gm...> - 2009-06-25 15:15:04
|
I have libatk installed as part of Ubuntu 9.04. Lots of things depend on it. On Thu, Jun 25, 2009 at 10:51 AM, Benny Malengier<ben...@gm...> wrote: > 2009/6/25 Gerald Britton <ger...@gm...>: >> You could be right and I will check out that debugger. In the >> meantime, here's something interesting. With those print statements >> in place, I started gramps: >> >> jerryb1@ubuntu:~/gramps32$ python src/gramps.py > /tmp/out >> error: duplicate REP tables used >> Failure loading aff file /usr/share/myspell/dicts/en_ZA.aff >> ^Z[1] Done python src/gramps.py > /tmp/out >> >> [2]+ Stopped python src/gramps.py > /tmp/out >> jerryb1@ubuntu:~/gramps32$ bg >> [2]+ python src/gramps.py > /tmp/out & >> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >> 0 /tmp/out >> >> Then, I opened People View and clicked on person id I44 (Lewis Anderson Garner) >> >> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >> 3597 /tmp/out >> >> Note that that is about 1.75 times the number of people in the db. >> Then I clicked on the person above I44 who is I1105 (Lewis Garner) >> >> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >> 5397 /tmp/out >> >> 1800 calls to first_child! Then I clicked back on i44 >> >> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >> 6596 /tmp/out >> >> Another 1200 calls. Back to I2205 >> >> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >> 7797 /tmp/out >> >> Another 1200 calls. Finally I exited gramps >> jerryb1@ubuntu:~/gramps32$ >> >> I know that this is unscientific, but to me it indicates that there is >> something amiss. I, of course, am generating the X events by clicking >> one row up or one row down. I can't see why it is necessary to run >> through so many people every time this happens, though. > > When you click, the selection color changes, and the treeview is > redrawn, on mouseover it might be needed to show help, so he redraws. > Every time he probably goes back to the model to see if there was a > change, and if so asks a number up and down of the visibile area to > see if the positioning remains the same (like scrollbars). If the > drawing is implemented efficiently, they would however notice no > row_inserted, .... signal was recieved, so nothing changed, and they > need not request so many data, only the row that is left and the row > that is put in selection as those are redrawn. > > I'll check at home on my box how many prints I have, but I expect I > will only have 1 or 2. > As we have had problems in the past, I hope you have no assistive > technologies (read atk) installed? > > Benny > -- Gerald Britton |
From: Gerald B. <ger...@gm...> - 2009-06-25 15:21:58
|
fwiw, disabling assistive technologies made the problem go away. The calls to first_child are what I would expect. Something about atk that I really don't understand at all. On Thu, Jun 25, 2009 at 11:14 AM, Gerald Britton<ger...@gm...> wrote: > I have libatk installed as part of Ubuntu 9.04. Lots of things depend on it. > > On Thu, Jun 25, 2009 at 10:51 AM, Benny > Malengier<ben...@gm...> wrote: >> 2009/6/25 Gerald Britton <ger...@gm...>: >>> You could be right and I will check out that debugger. In the >>> meantime, here's something interesting. With those print statements >>> in place, I started gramps: >>> >>> jerryb1@ubuntu:~/gramps32$ python src/gramps.py > /tmp/out >>> error: duplicate REP tables used >>> Failure loading aff file /usr/share/myspell/dicts/en_ZA.aff >>> ^Z[1] Done python src/gramps.py > /tmp/out >>> >>> [2]+ Stopped python src/gramps.py > /tmp/out >>> jerryb1@ubuntu:~/gramps32$ bg >>> [2]+ python src/gramps.py > /tmp/out & >>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>> 0 /tmp/out >>> >>> Then, I opened People View and clicked on person id I44 (Lewis Anderson Garner) >>> >>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>> 3597 /tmp/out >>> >>> Note that that is about 1.75 times the number of people in the db. >>> Then I clicked on the person above I44 who is I1105 (Lewis Garner) >>> >>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>> 5397 /tmp/out >>> >>> 1800 calls to first_child! Then I clicked back on i44 >>> >>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>> 6596 /tmp/out >>> >>> Another 1200 calls. Back to I2205 >>> >>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>> 7797 /tmp/out >>> >>> Another 1200 calls. Finally I exited gramps >>> jerryb1@ubuntu:~/gramps32$ >>> >>> I know that this is unscientific, but to me it indicates that there is >>> something amiss. I, of course, am generating the X events by clicking >>> one row up or one row down. I can't see why it is necessary to run >>> through so many people every time this happens, though. >> >> When you click, the selection color changes, and the treeview is >> redrawn, on mouseover it might be needed to show help, so he redraws. >> Every time he probably goes back to the model to see if there was a >> change, and if so asks a number up and down of the visibile area to >> see if the positioning remains the same (like scrollbars). If the >> drawing is implemented efficiently, they would however notice no >> row_inserted, .... signal was recieved, so nothing changed, and they >> need not request so many data, only the row that is left and the row >> that is put in selection as those are redrawn. >> >> I'll check at home on my box how many prints I have, but I expect I >> will only have 1 or 2. >> As we have had problems in the past, I hope you have no assistive >> technologies (read atk) installed? >> >> Benny >> > > > > -- > Gerald Britton > -- Gerald Britton |
From: Benny M. <ben...@gm...> - 2009-06-25 18:43:24
|
2009/6/25 Gerald Britton <ger...@gm...>: > fwiw, disabling assistive technologies made the problem go away. The > calls to first_child are what I would expect. Something about atk > that I really don't understand at all. Well, it provides access for screen readers and stuff like that. But I have the impression it is really bad for GTK apps as they start to behave in ways their creators never intended (slowing down, crashing, ....). We don't explicitly support it, so in my mind it should be disabled. That is, it should be an explicit opt in system. You have to image how many people have had bad experience with GRAMPS due to atk being enabled. We need some sort of flag to make atk not be enabled for the GRAMPS application. I have always been shielded from atk due to the fact I use KDE ;-) Benny > > On Thu, Jun 25, 2009 at 11:14 AM, Gerald > Britton<ger...@gm...> wrote: >> I have libatk installed as part of Ubuntu 9.04. Lots of things depend on it. >> >> On Thu, Jun 25, 2009 at 10:51 AM, Benny >> Malengier<ben...@gm...> wrote: >>> 2009/6/25 Gerald Britton <ger...@gm...>: >>>> You could be right and I will check out that debugger. In the >>>> meantime, here's something interesting. With those print statements >>>> in place, I started gramps: >>>> >>>> jerryb1@ubuntu:~/gramps32$ python src/gramps.py > /tmp/out >>>> error: duplicate REP tables used >>>> Failure loading aff file /usr/share/myspell/dicts/en_ZA.aff >>>> ^Z[1] Done python src/gramps.py > /tmp/out >>>> >>>> [2]+ Stopped python src/gramps.py > /tmp/out >>>> jerryb1@ubuntu:~/gramps32$ bg >>>> [2]+ python src/gramps.py > /tmp/out & >>>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>>> 0 /tmp/out >>>> >>>> Then, I opened People View and clicked on person id I44 (Lewis Anderson Garner) >>>> >>>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>>> 3597 /tmp/out >>>> >>>> Note that that is about 1.75 times the number of people in the db. >>>> Then I clicked on the person above I44 who is I1105 (Lewis Garner) >>>> >>>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>>> 5397 /tmp/out >>>> >>>> 1800 calls to first_child! Then I clicked back on i44 >>>> >>>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>>> 6596 /tmp/out >>>> >>>> Another 1200 calls. Back to I2205 >>>> >>>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>>> 7797 /tmp/out >>>> >>>> Another 1200 calls. Finally I exited gramps >>>> jerryb1@ubuntu:~/gramps32$ >>>> >>>> I know that this is unscientific, but to me it indicates that there is >>>> something amiss. I, of course, am generating the X events by clicking >>>> one row up or one row down. I can't see why it is necessary to run >>>> through so many people every time this happens, though. >>> >>> When you click, the selection color changes, and the treeview is >>> redrawn, on mouseover it might be needed to show help, so he redraws. >>> Every time he probably goes back to the model to see if there was a >>> change, and if so asks a number up and down of the visibile area to >>> see if the positioning remains the same (like scrollbars). If the >>> drawing is implemented efficiently, they would however notice no >>> row_inserted, .... signal was recieved, so nothing changed, and they >>> need not request so many data, only the row that is left and the row >>> that is put in selection as those are redrawn. >>> >>> I'll check at home on my box how many prints I have, but I expect I >>> will only have 1 or 2. >>> As we have had problems in the past, I hope you have no assistive >>> technologies (read atk) installed? >>> >>> Benny >>> >> >> >> >> -- >> Gerald Britton >> > > > > -- > Gerald Britton > |
From: Benny M. <ben...@gm...> - 2009-06-25 19:25:26
|
Did some googling. Depressing stuff. See https://bugs.launchpad.net/nautilus/+bug/159042 and duplicate bugs. All fixed with disabling ATK, but still, it is on by default. Gerald, do you add to that one of those bug entries indicating downstream really suffers from this (as in gets a bad name for being slow software) Benny 2009/6/25 Benny Malengier <ben...@gm...>: > 2009/6/25 Gerald Britton <ger...@gm...>: >> fwiw, disabling assistive technologies made the problem go away. The >> calls to first_child are what I would expect. Something about atk >> that I really don't understand at all. > > Well, it provides access for screen readers and stuff like that. > But I have the impression it is really bad for GTK apps as they start > to behave in ways their creators never intended (slowing down, > crashing, ....). We don't explicitly support it, so in my mind it > should be disabled. That is, it should be an explicit opt in system. > You have to image how many people have had bad experience with GRAMPS > due to atk being enabled. > > We need some sort of flag to make atk not be enabled for the GRAMPS > application. > I have always been shielded from atk due to the fact I use KDE ;-) > > Benny > >> >> On Thu, Jun 25, 2009 at 11:14 AM, Gerald >> Britton<ger...@gm...> wrote: >>> I have libatk installed as part of Ubuntu 9.04. Lots of things depend on it. >>> >>> On Thu, Jun 25, 2009 at 10:51 AM, Benny >>> Malengier<ben...@gm...> wrote: >>>> 2009/6/25 Gerald Britton <ger...@gm...>: >>>>> You could be right and I will check out that debugger. In the >>>>> meantime, here's something interesting. With those print statements >>>>> in place, I started gramps: >>>>> >>>>> jerryb1@ubuntu:~/gramps32$ python src/gramps.py > /tmp/out >>>>> error: duplicate REP tables used >>>>> Failure loading aff file /usr/share/myspell/dicts/en_ZA.aff >>>>> ^Z[1] Done python src/gramps.py > /tmp/out >>>>> >>>>> [2]+ Stopped python src/gramps.py > /tmp/out >>>>> jerryb1@ubuntu:~/gramps32$ bg >>>>> [2]+ python src/gramps.py > /tmp/out & >>>>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>>>> 0 /tmp/out >>>>> >>>>> Then, I opened People View and clicked on person id I44 (Lewis Anderson Garner) >>>>> >>>>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>>>> 3597 /tmp/out >>>>> >>>>> Note that that is about 1.75 times the number of people in the db. >>>>> Then I clicked on the person above I44 who is I1105 (Lewis Garner) >>>>> >>>>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>>>> 5397 /tmp/out >>>>> >>>>> 1800 calls to first_child! Then I clicked back on i44 >>>>> >>>>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>>>> 6596 /tmp/out >>>>> >>>>> Another 1200 calls. Back to I2205 >>>>> >>>>> jerryb1@ubuntu:~/gramps32$ wc -l /tmp/out >>>>> 7797 /tmp/out >>>>> >>>>> Another 1200 calls. Finally I exited gramps >>>>> jerryb1@ubuntu:~/gramps32$ >>>>> >>>>> I know that this is unscientific, but to me it indicates that there is >>>>> something amiss. I, of course, am generating the X events by clicking >>>>> one row up or one row down. I can't see why it is necessary to run >>>>> through so many people every time this happens, though. >>>> >>>> When you click, the selection color changes, and the treeview is >>>> redrawn, on mouseover it might be needed to show help, so he redraws. >>>> Every time he probably goes back to the model to see if there was a >>>> change, and if so asks a number up and down of the visibile area to >>>> see if the positioning remains the same (like scrollbars). If the >>>> drawing is implemented efficiently, they would however notice no >>>> row_inserted, .... signal was recieved, so nothing changed, and they >>>> need not request so many data, only the row that is left and the row >>>> that is put in selection as those are redrawn. >>>> >>>> I'll check at home on my box how many prints I have, but I expect I >>>> will only have 1 or 2. >>>> As we have had problems in the past, I hope you have no assistive >>>> technologies (read atk) installed? >>>> >>>> Benny >>>> >>> >>> >>> >>> -- >>> Gerald Britton >>> >> >> >> >> -- >> Gerald Britton >> > |