-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Very long loading times when opening the same FileGDB the second time #27790
Comments
Author Name: Casper Børgesen (Casper Børgesen) Casper Børgesen wrote:
I wanted to see if ESRI had the same problem and I repeated the test in ArcGIS Pro:
QGIS seems to keep a lock on all feature types when the FileGDB is open, where ArcGIS Pro doesn't. I think that could be the cause to why QGIS is slower when removing all the layers. |
Author Name: Giovanni Manghi (@gioman) Does it work differently in QGIS 2.18?
|
Author Name: Casper Børgesen (Casper Børgesen) Giovanni Manghi wrote:
I have just tried on the two machines and QGIS 2.18 has the issue already in step 2. Would it help if I recorded a video of what I am doing along with all the file activity in the @gdb@ folder?
|
Author Name: Giovanni Manghi (@gioman) Casper Børgesen wrote:
so not a regression.
yes please.
|
Author Name: Casper Børgesen (Casper Børgesen) Giovanni Manghi wrote:
I have uploaded a short video to youtube where you can see whats happening in QGIS and in the FileGDB folder when loading and removing the FileGDB from QGIS. |
Author Name: Giovanni Manghi (@gioman) Just tested on master/linux and the operations as you show them in the screencast are basically instantaneous.
|
Author Name: Casper Børgesen (Casper Børgesen) Giovanni Manghi wrote:
I am only on Windows so I can't provide feedback regarding Linux.
|
Author Name: Casper Børgesen (Casper Børgesen) Giovanni Manghi wrote:
I just uninstalled the OGR FileGDB driver and reran the tests. Without the OGR FileGDB driver I probably get the same instantaneous loading like you do. I guess that you don't have the OGR FileGDB driver installed (since I expect it to be Windows only?). I have tried the same tests with and without the OGR FileGDB driver installed on my private PC (which isn't infected by any ESRI products) and I get the same results, with the driver its very slow and without its very fast. In most cases I need the write capability of the OGR FileGDB driver and I haven't found an easy way to select which driver to use - besides (un)installing :s So I think this issue is related to the OGR FileGDB driver (or how it is used by QGIS). |
Author Name: Giovanni Manghi (@gioman) Casper Børgesen wrote:
I just tested with both the proprietary "ogr filegdb" (esri fliegdb) available to be installed manually with osgeo4w and the open source one (openFileGDB) is installed by default (as is part of ogr) on any operating system when installing QGIS. On Windows 10/QGIS 3.2 (osgeo4w) I can't notice any delay or long wait when adding/removing/re-adding your datasource. Have you tried on a clean profile? |
Author Name: Casper Børgesen (Casper Børgesen) Giovanni Manghi wrote:
What do you mean by a clean profile? |
Author Name: Giovanni Manghi (@gioman) Casper Børgesen wrote:
In QGSI3 you can have multiple profiles (settings > user profiles). Testing in a new profile is necessary to exclude issues caused by 3rd party plugins and/or legacy configurations. |
Author Name: Casper Børgesen (Casper Børgesen) Giovanni Manghi wrote:
I have created a new profile and using that profile I still get the same slow results :( |
Author Name: Andrea Giudiceandrea (@agiudiceandrea) I can reproduce the issue on Windows 7 64 bit (core i5, 8GB) with QGIS 3.3.0-Master (3032af2) (qgis-dev-3.3.0-84) 64 bit. The issue only happens when the testdata_2.gdb directory (extracted from the provided zip file) is dragged and dropped in the map or when the layers are added through "Add vector layer | Data Source Manager | Vector" / "Source Type: Directory" and only if the GDAL/OGR FileGDB driver plugin (gdal-filegdb 2.2.4-2) is installed (regardless of the Source format chosen among "OpenFileGDB" and "ESRI FileGDB"). I can also confirm that the slowdowns seem related to the creation of lock files in the testdata_2.gdb directory during the import/removal operations. It doesn't happen if the GDAL/OGR FileGDB driver plugin is not installed. It doesn't happen if the provided testdata_2.gdb.zip file (not the extracted testdata_2.gdb directory) is dragged and dropped into the map (regardless the GDAL/OGR FileGDB driver plugin is installed or not). |
Author Name: Giovanni Manghi (@gioman) Andrea Giudiceandrea wrote:
weird, I'm pretty sure I tested this scenario on a clean environment (VM snapshot) and I could not confirm. Anyway, if this observation is right then the title and description of this ticket should be changed to better reflect the source of the issue.
|
Author Name: Casper Børgesen (Casper Børgesen) Giovanni Manghi wrote:
I am not allowed to change anything related to the question or subject.
|
Author Name: Giovanni Manghi (@gioman) Casper Børgesen wrote:
suggest a new title and I will change it afterwards. |
Author Name: Casper Børgesen (Casper Børgesen) Giovanni Manghi wrote:
Title: Slow performance when using OGR FileGDB driver to read file geodatabases. Description:
It might be related to issue #26232 where Even Rouault did some optimizations. Steps to reproduce (https://www.youtube.com/watch?v=hvcPVObfBFA):
|
Author Name: Giovanni Manghi (@gioman)
should not reflect the finding from here? |
Author Name: Casper Børgesen (Casper Børgesen) Giovanni Manghi wrote:
If I compare to using the OpenFileGDB driver, then the performance is slower (not as instantaneous as the OpenFileGDB driver) all the time - no matter if I use 2.18, 3.2 or MASTER. The issue seems to be much more severe the second time I load the data set, which is what I try to show in the video. |
Author Name: Giovanni Manghi (@gioman)
so you don't confirm only when the layers are added in the ways as stated here? #27790 (comment) (edited) from that comment I deduce that if the layers are added using the QGIS Browser the issue does not show(?). |
Author Name: Andrea Giudiceandrea (@agiudiceandrea) Giovanni Manghi wrote:
With the GDAL/OGR FileGDB driver plugin installed, using the Browser panel to add the layers to the map it seems that the second time is not slower then the first time: they are almost equally slow (it's a matter of minutes for add or remove the layers). Without the FileGDB driver plugin, each task takes just a few seconds. |
I can't seem to replicate this issue anymore, I can drag the layers onto QGIS without any issue, it takes 1/2 seconds replicating each step mentioned in the ticket. Also I did not use any plugins, just a fresh profile. (QGIS 3.16,14 and 3.22.1., tested on Windows 10). |
The QGIS project highly values your report and would love to see it addressed. However, this issue has been left in feedback mode for the last 14 days and is being automatically marked as "stale". |
While we hate to see this happen, this issue has been automatically closed because it has not had any activity in the last 42 days despite being marked as feedback. If this issue should be reconsidered, please follow the guidelines in the previous comment and reopen this issue. |
Author Name: Casper Børgesen (Casper Børgesen)
Original Redmine Issue: 19968
Affected QGIS version: 3.3(master)
Redmine category:data_provider/ogr
The problem and how to reproduce:
As seen on the above timings loading the same FileGDB the second time is magnitudes slower than the first time around.
All I can see is that a lot of locking/unlocking of the files @GDB_Items@ and @GDB_ItemTypes@ during all the processes.
It might be related to issue #26232 where Even Rouault did some optimization.
I have attached the test data set used for the timings above (the same as used in issue #26232).
My tests was done on a Laptop with an SSD hard-drive but the issue is also present on my workstation.
I have installed QGIS nightly using OSGeo4W x64 and the package @gdal-filegdb@ is also installed.
I have ArcMap 10.6 and ArcGIS Pro 2.2 installed.
The text was updated successfully, but these errors were encountered: