My Gramps is sometimes quick (3-4 seconds) and sometimes slooooow (50-90 seconds) when I use the Place Selector as part of adding events.
It is probably going to take more users looking for patterns. So, this is a plea for more people to become keen observers of the Place Selector behavior.
My workflow has distorted to the point where I clipboard all Places while adding Events so that I can AVOID return visits to the Place selector as often as possible. And I’d like to undermine this aversion before it becomes a phobia.
My Place Tree is hierarchy of 3600. All hand added entries, some updated with the Place Cleanup addon. I know that there are some duplicates and potentially some enclosure oddities, like loops. My hierarchy starts with Continents.
(Originally, my hierarchy had a top level of ‘Terra’ because I am also a space enthusiast. That seemed to cause weirdness with GIS and added a drill-down level in the Place Selector. I dread beginning to log events outside Terra. I currently use the normal border-bridging vessel… like trains, planes, ships, & submarines… ambiguities for the ISS & low-orbit launch vehicles. But the 1968 lunar landing & Mars landers breaks that metaphor. And Voyager 1 entered interstellar space in 2012.)
An observation:
A View with a Custom Filter applied can exhibit a similar delay showing records. Populating a filtered view is massively slower compared to an unfiltered View.
Might the Place Selector be affected by filters and Gramplets currently active in the Places view or Events view?
I am positive that Gramplets in the Sidebar & Bottombar affect the GUI performance, even when they aren’t to top tab and should be idle. The Filter Gramplet HAS to remain in effect for it to work in concert with other Gramplets & Views. (The Geography view seems to leverage this a LOT.)
And the Undocked Gramplets would always need to refresh to keep context current as the focus (active objection selection) changes.
I love the Pedigree & Deep Connections Gramplets. But they nearly kill the responsiveness of the GUI. And they REALLY don’t need to be doing anything when they aren’t at the top of the stack of tabs.
For those who want to see if their issues might be related to overactive Gramplets; @SNoiraud has been kind enough to create 2 experimental variants for manually controlling refresh in Gramplets:
This could become an issue as more and more delightful ‘Views’ are assembled by enterprising devs and used as they will be when the views become detachable. In my case if I could, I would use 4 detachable views, each one with its own filtering, so without some clever way to limit the load on the system, we might grind to a complete halt. Is this a limitation of single threading?
There are several feature requests discussing multi-threading, multi-single-threading and process isolation. And those all have the potential to mask some of the symptoms. (I’d love to see multi-core support. That kind of optimization is a specialized skillset. So, until somebody joins with that skill, it’s doubtful we’re headed that direction.)
But nothing else was going on… and there must be a reason that the Place Selector is sucking extra power. So rather than throw more CPU cycles at a leak, it’d be better to fix the leak.
When we use filtering, if I remember, we use a proxy to cache all the selected objects. All selected objects are copied. It takes some time to do that. If you use different filtering for each views, you’ll have one cache for each view. It takes memory and time. I don’t know if we really can use multithreading for that. And what about the complexity of such a proposal ?
I was trying to communicate that multi-threading was not an appropriate solution to THIS problem … but it still seemed very desirable for other issues.
Reports look like they would have the fewest complications when implementing multi-threading. The are the “low hanging fruit.” But since Gramps pegs a single core at 100% for more than 15 seconds while leaving other cores idle, there are other (more difficult) targets that should not be dismissed.
Microsoft initially decided more than 2 cores were too hard to coordinate for Excel. (Improvements to threading have helped let them use more cores more broadly. But there were tradeoffs in wasting memory with caching) But excel users also found ways to design heavy load spreadsheets that work better for multi-threading. It could be that some heavy load tools & Gramplets could be made to prefer idle cores…
I thought it was, but:
sqlite3.ProgrammingError: SQLite objects created in a thread can only be used in that same thread. The object was created in thread id 140238146201408 and this is thread id 140237518923520.
3600 places shouldn’t take that long or do you have 36000 places?
I have ~3000 places in my database and the populating of the selector takes ~3 seconds.
You’re exactly right. Sometimes, populating the Place Selector takes 3-4 seconds and this makes me a happy user.
But, for an unknown reason, Gramps will suddenly take a lot longer. And, since the dialog is modal, all I can do is pre-type a place search string. Gramps will OFTEN be able to even FIND a match but it won’t let me apply it to the event. It is still busy doing something. So I can Esc out (the Cancel button is unresponsive until whatever busy task is complete) or wait.
So I go read an eMail… because it seems to take longer when I watch.
This a very painful process when adding at least 3 Places (for Birth, Death, Burial) for each Person. I run out of quick reading items.
Since you specify Windoze, you might want to activate the performance monitor and set it up to highlight Gramps process. I’d be curious to hear if it was experiencing paging, or was only running 100% of a core.
And a look at the overall memory utilization during one of these long events may also provide some clues.
On a system with some memory constraints, it is possible that Python is doing some more extensive garbage collection at an inopportune time. Python normally is quite good at spreading this out so it doesn’t impact performance noticeably, but the filling of the place selector does a LOT of Python object creation and discard as the entire places db is scanned and arranged into the tree structure. Gtk is also grabbing memory as well.
The performance monitor would not spot Python Garbage collection, but it would give clues about the overall system memory utilization, and, if paging is going on, might help explain the issue.
How very frustrating. I was anxious to do as you suggested. So I dove in yesterday to add cousins through a maternal great-grandmother before an upcoming reunion.
And for the 1st time since… (actually, I cannot remember another day where this has happened)… Gramps did not have an instance where the Place Selector slowed down.
I even had GIMP up with a scanned image, sucking memory. And Firefox grabbing resources for a multitude of FindAGrave & FamilySearch tabs. But Gramps behaved with perfect table manners.
(Of course, there were the expected complaints when I would try to ‘ok’ spawned dialogs too quickly in sequence… trying to submit commits before the last was done. But I don’t think Gramps has ever known how to queue.)
I don’t know if its the same phenomenon but while merging two places which usualy takes seconds this time it takes 3 or 4 minutes. The perfmon screen capture (nothing special for this 3/4 minutes merge):
This is aggravating!! For the 1st time in 19 days (a new record for my system), populating the Place Tree slowed down. (I had just added 2 Cemeteries) Since I could not remember what data you wanted, I had to come back to Discourse to search.
I launched the Performance Monitor and… you guessed it… the Place Tree was populating in 3-4 seconds again.
I’ve been launching from the Command line in hopes of an error log.
But the buffer was full of "WARNING: Attempt to add node twice to the model " messages
WARNING: Attempt to add node twice to the model (Cole: ed277985ebb2cf62198733f2f5c)
WARNING: Attempt to add node twice to the model (Harding: ed277b40b9f720d4cad59f9f453)
WARNING: Attempt to add node twice to the model (Huckins: ed277e4d7c74a18e0f0d0401eea)
WARNING: Attempt to add node twice to the model (Chipman: ed277e7030b37a3bab00e0e18e3)
WARNING: Attempt to add node twice to the model (Cobb: ed278035ca8668e3b612bc7d046)
WARNING: Attempt to add node twice to the model (Chipman: ed278262cf259f75ca654a1eabf)
WARNING: Attempt to add node twice to the model (Howland: ed2782b5bcb1ff04ee568b75c64)
(gramps.exe:11368): Gdk-CRITICAL **: gdk_frame_clock_get_frame_time: assertion 'GDK_IS_FRAME_CLOCK (frame_clock)' failed
Just been search the Wiki and Mail Archive to see if there is an error log file I can access.
The docs for the Warning icon in the toolbar says that it will display the last 20 errors. Where is that data stored? Can I force the Warning Icon to appear?
(Hmmm. That ‘Warning’ is a lightbulb icon. Which is ‘information’, not ‘Warning’. Would that be an error in the documentation or the application?)
The timer-based backup is turned off. Gramps is only doing backups upon exit. I used it quite a bit while beta testing features. And also when troubleshooting how it impacted operations when waking the OS.
(Although if it looks like there is a LOT of info to be flowed in for a session, I tend to enable it temporarily to minimize risk.)
Actually, those are People rather than Places… another thing to troubleshoot! (All new additions today except 1 merge… Mayflower descendant cousins where I’m trying to untangle a questionable link.)
