[Bug] GUI startup delay

[HuidaeCho]

Describe the bug
I have 5367 vectors and 6759 rasters in many mapsets/locations in my GRASS database. When I start GRASS GUI, there is about a 25-second delay (hourglass cursor) and I cannot do anything during this wait in GUI. It doesn't matter in which mapset I start. Even from a brand new mapset without any data.

To Reproduce

1. Create a lot of vector s and rasters
2. Start g.gui
3. Wait 25-30 seconds before being able to do anything in GUI

Expected behavior
Load the Data catalog in the background.

OR an option to disable and remove the Data catalog.

Screenshots
I cannot show my time.

System description (please complete the following information):

• Operating System: Linux
• GRASS GIS version: master

Additional context
I would have a faster GUI than a user-friendly but slow one. Ideally, any long-running tasks should be done in the background to enhance user experience. Please do not assume that there are only a handful of maps in one database.

[petrasovaa]

Please see discussion in #749. What you are reporting is surprising to me, we have already taken some steps to mitigate this problem. At the same time I assume we could improve it. However, loading is already done in the background and should be run in parallel (on the level of locations). So when I start gui, I can immediately start using it. I tested large number of layers and I get nowhere close to 30 s. I found what takes time is showing the content of a mapset (current mapset is unfolded by default), can you see a difference depending in which mapset you start? Also how are your data distributed, e.g. do you have a lot of locations/mapsets or rather a lot of rasters/vectors in a few locations/mapsets?
I haven't tested the catalog on older computers, my laptop is fairly new. Could that be an issue?

[nilason]

As I mentioned before #749 (comment), working with wxPython 4.1.0 increases significantly the startup speed, even though it could always be improved.

As a general note I must say the new GUI is a major step forward against user friendliness and productivity. Please do note the new possibility to use several grassdata databases (adding, removing at will). I don't know about your workflow, but I can hardly imagine you are using actively all locations at once. Consider if you can change this to decrease startup load time.
I for one, use at least three grassdata dbs: (1) active projects, (2) old projects, (3) one (minimal one) for GRASS development and testing. If you occasionally need access to a location in another db, just add it.

[HuidaeCho]

As a general note I must say the new GUI is a major step forward against user friendliness and productivity. Please do note the new possibility to use several grassdata databases (adding, removing at will). I don't know about your workflow, but I can hardly imagine you are using actively all locations at once. Consider if you can change this to decrease startup load time.

@nilason Please don't get me wrong. I'm not saying that the new startup is bad. I like it and it can be a game changer for any GRASS users. I just want to help improve it. Reorganizing my database is only a workaround and it would impact my workflow. Having to reorganize my data every time something new is added and slows me down is just not a solution.

[HuidaeCho]

can you see a difference depending in which mapset you start? Also how are your data distributed, e.g. do you have a lot of locations/mapsets or rather a lot of rasters/vectors in a few locations/mapsets?
I haven't tested the catalog on older computers, my laptop is fairly new. Could that be an issue?

I have 18 locations and 49 mapsets in total. My CPU is rather old (Xeon(R) CPU E5620 @ 2.40GHz) and I have an HDD. It could be the issue. I just created a new database and tried an empty mapset. The GUI displays all databases anyway and it took almost the same 32 seconds. I can see it does a kind of a background process because clicking different tabs or buttons responds slowly until the hourglass icon is cleared. For example, I can immediately switch the tab to Display and clicking other tabs doesn't seem to work. Click the raster icon and wait about 5-10 seconds and the dialog eventually opens. By that time, I already clicked other tools multiple times and all of a sudden, all those dialogs open at the same time.

I tried my relative new laptop (i5-7300U @ 2.60GHz) with an SSD. There are 4384 vectors and 2740 rasters across 26 mapsets in 7 locations. It took 7 seconds to clear the hourglass. That's about 59% of the above computer in the number of maps and 23% of the delay. Maybe, it's my old CPU?

[HuidaeCho]

As I mentioned before #749 (comment), working with wxPython 4.1.0 increases significantly the startup speed, even though it could always be improved.

As a general note I must say the new GUI is a major step forward against user friendliness and productivity. Please do note the new possibility to use several grassdata databases (adding, removing at will). I don't know about your workflow, but I can hardly imagine you are using actively all locations at once. Consider if you can change this to decrease startup load time.
I for one, use at least three grassdata dbs: (1) active projects, (2) old projects, (3) one (minimal one) for GRASS development and testing. If you occasionally need access to a location in another db, just add it.

@nilason I don't think this method actually works because the GUI lists all my previously opened databases no matter where they are. Looks like the GUI caches this list.

@petrasovaa Would it be possible to load just the current mapset, location, or database optionally for a slow computer if the issue is my machine? Until the user opens something else? I mean as an optional setting.

[veroandreo]

As I mentioned before #749 (comment), working with wxPython 4.1.0 increases significantly the startup speed, even though it could always be improved.
As a general note I must say the new GUI is a major step forward against user friendliness and productivity. Please do note the new possibility to use several grassdata databases (adding, removing at will). I don't know about your workflow, but I can hardly imagine you are using actively all locations at once. Consider if you can change this to decrease startup load time.
I for one, use at least three grassdata dbs: (1) active projects, (2) old projects, (3) one (minimal one) for GRASS development and testing. If you occasionally need access to a location in another db, just add it.

@nilason I don't think this method actually works because the GUI lists all my previously opened databases no matter where they are. Looks like the GUI caches this list.

I cannot reproduce this. I have used different databases, but I don't get all of them listed.

@petrasovaa Would it be possible to load just the current mapset, location, or database optionally for a slow computer if the issue is my machine? Until the user opens something else? I mean as an optional setting.

AFAIU, this is the default behavior. I only get the maps in the current mapset listed. To see others, I must click on them, and according to the number of maps there, it takes shorter or longer to load (micro seconds to seconds). Just to be sure, do you use the newest grass-dev?

[petrasovaa]

As I mentioned before #749 (comment), working with wxPython 4.1.0 increases significantly the startup speed, even though it could always be improved.
As a general note I must say the new GUI is a major step forward against user friendliness and productivity. Please do note the new possibility to use several grassdata databases (adding, removing at will). I don't know about your workflow, but I can hardly imagine you are using actively all locations at once. Consider if you can change this to decrease startup load time.
I for one, use at least three grassdata dbs: (1) active projects, (2) old projects, (3) one (minimal one) for GRASS development and testing. If you occasionally need access to a location in another db, just add it.

@nilason I don't think this method actually works because the GUI lists all my previously opened databases no matter where they are. Looks like the GUI caches this list.

I cannot reproduce this. I have used different databases, but I don't get all of them listed.

Seems like there is some confusion around databases here. You can add a database and that database is then saved in settings so GUI remembers it for next time it is opened. If you remove it from data catalog, it's removed from settings and disappears.

@petrasovaa Would it be possible to load just the current mapset, location, or database optionally for a slow computer if the issue is my machine? Until the user opens something else? I mean as an optional setting.

AFAIU, this is the default behavior. I only get the maps in the current mapset listed. To see others, I must click on them, and according to the number of maps there, it takes shorter or longer to load (micro seconds to seconds). Just to be sure, do you use the newest grass-dev?

No, at this point everything is loaded (in a virtual tree), but only current mapset is displayed. I agree we should limit the loading for slow computers/large databases. The loading could be limited to current location only for example if it takes too much time and the rest could be reloaded on demand. The changes are feasible, but not super trivial.

[HuidaeCho]

As I mentioned before #749 (comment), working with wxPython 4.1.0 increases significantly the startup speed, even though it could always be improved.
As a general note I must say the new GUI is a major step forward against user friendliness and productivity. Please do note the new possibility to use several grassdata databases (adding, removing at will). I don't know about your workflow, but I can hardly imagine you are using actively all locations at once. Consider if you can change this to decrease startup load time.
I for one, use at least three grassdata dbs: (1) active projects, (2) old projects, (3) one (minimal one) for GRASS development and testing. If you occasionally need access to a location in another db, just add it.

@nilason I don't think this method actually works because the GUI lists all my previously opened databases no matter where they are. Looks like the GUI caches this list.

I cannot reproduce this. I have used different databases, but I don't get all of them listed.

By listing databases, I meant that visually collapsed databases are listed under the tree. I still have to click one to expand it.

@petrasovaa Would it be possible to load just the current mapset, location, or database optionally for a slow computer if the issue is my machine? Until the user opens something else? I mean as an optional setting.

AFAIU, this is the default behavior. I only get the maps in the current mapset listed. To see others, I must click on them, and according to the number of maps there, it takes shorter or longer to load (micro seconds to seconds). Just to be sure, do you use the newest grass-dev?

From my experience, the GUI seems to load everything from listed databases, not just from the current mapset or current location or not even current database.

[HuidaeCho]

As I mentioned before #749 (comment), working with wxPython 4.1.0 increases significantly the startup speed, even though it could always be improved.
As a general note I must say the new GUI is a major step forward against user friendliness and productivity. Please do note the new possibility to use several grassdata databases (adding, removing at will). I don't know about your workflow, but I can hardly imagine you are using actively all locations at once. Consider if you can change this to decrease startup load time.
I for one, use at least three grassdata dbs: (1) active projects, (2) old projects, (3) one (minimal one) for GRASS development and testing. If you occasionally need access to a location in another db, just add it.

@nilason I don't think this method actually works because the GUI lists all my previously opened databases no matter where they are. Looks like the GUI caches this list.

I cannot reproduce this. I have used different databases, but I don't get all of them listed.

Seems like there is some confusion around databases here. You can add a database and that database is then saved in settings so GUI remembers it for next time it is opened. If you remove it from data catalog, it's removed from settings and disappears.

Oh! I didn't know that. Then, how can I add them back? By starting in a removed database from the terminal? Or does the GUI have a button for adding a database?

@petrasovaa Would it be possible to load just the current mapset, location, or database optionally for a slow computer if the issue is my machine? Until the user opens something else? I mean as an optional setting.

AFAIU, this is the default behavior. I only get the maps in the current mapset listed. To see others, I must click on them, and according to the number of maps there, it takes shorter or longer to load (micro seconds to seconds). Just to be sure, do you use the newest grass-dev?

No, at this point everything is loaded (in a virtual tree), but only current mapset is displayed. I agree we should limit the loading for slow computers/large databases. The loading could be limited to current location only for example if it takes too much time and the rest could be reloaded on demand. The changes are feasible, but not super trivial.

Ideally, it would be best to load only the current mapset on start, and load other mapsets on demand. Mapset by mapset, not location or database based. Or make it configurable? Sounds like I'm asking for too much ;).

[petrasovaa]

Seems like there is some confusion around databases here. You can add a database and that database is then saved in settings so GUI remembers it for next time it is opened. If you remove it from data catalog, it's removed from settings and disappears.

Oh! I didn't know that. Then, how can I add them back? By starting in a removed database from the terminal? Or does the GUI have a button for adding a database?

In the data catalog toolbar there is Add existing or create new database and when you right click, there is Remove GRASS database from data catalog.

@petrasovaa Would it be possible to load just the current mapset, location, or database optionally for a slow computer if the issue is my machine? Until the user opens something else? I mean as an optional setting.

AFAIU, this is the default behavior. I only get the maps in the current mapset listed. To see others, I must click on them, and according to the number of maps there, it takes shorter or longer to load (micro seconds to seconds). Just to be sure, do you use the newest grass-dev?

No, at this point everything is loaded (in a virtual tree), but only current mapset is displayed. I agree we should limit the loading for slow computers/large databases. The loading could be limited to current location only for example if it takes too much time and the rest could be reloaded on demand. The changes are feasible, but not super trivial.

Ideally, it would be best to load only the current mapset on start, and load other mapsets on demand. Mapset by mapset, not location or database based. Or make it configurable? Sounds like I'm asking for too much ;).

Loading only current mapset is fine, configuring it might be too much at this point...

[HuidaeCho]

Loading only current mapset is fine

That'll be great!

[petrasovaa]

Not quite complete, but please try #1434.

[mlennert]

@HuidaeCho can you tell us if this is still a problem ?

[wenzeslaus]

This was addressed by #1434 which is now merged. Please open a new issue if needed.