Relative performance with complex collections

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Relative performance with complex collections

Bryan Hall-2
Classification: DCL-Internal

Recently at work I was asked to look into some issues about performance (of course blaming it on the database) when used with ArcGIS. I thought it would be interesting to share my findings, especially showing the huge difference in performance. Well done QGIS team:

This is not an Oracle issue, or a network issue. For example, doing a select all on RSP_12_SLOPE returns 10 rows. Yes those geometry collections on each row are huge, and the total volume of data is about 37 MB, but the query and transfer time from the production DB to my slow laptop is usually less than one second (longest was 4 seconds). With ArcGIS this query time averages about 5 seconds. So that data is on the client computer reasonably quickly.

OBJECTID                              SDO_UTIL.GETNUMVERTICES(A.SHAPE)
1713                                  287874
1714                                  184606
1715                                  24827
1716                                  269514
1717                                  399577
1718                                  34207
1719                                  877
1720                                  112925
1721                                  376208
1722                                  228223

To render those 10 rows on-screen (full extents) takes (minutes:seconds) from slowest to quickest:

ArcGIS Pro 2.2 = Initial draw - 4:48, Redraw ? (Waited 8 minutes and gave up)
ArcMap 10.5 = 2:58
FME Viewer 2018 = 1:56
Manifold Viewer 9.0 = Initial draw - 1:46, Redraw - 1:30
QGIS Boundless Desktop 1.1 = 0:07

This is obviously an ESRI code issue. I won't sugar coat this - their render code performance stinks in ArcGIS classic, and appears to be even worse in the new Pro version. Based on my observations I have to assume their on-the-fly conversion routines from the Oracle SDO_GEOMETRY to their internal render format are horribly inefficient. I see this not only with these large collections, but also with simple points where there are thousands of points being rendered on the screen.



This email (and attachments if any) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is confidential or privileged and exempt from disclosure under applicable law. If the reader of this email is not the intended recipient, or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return email and destroy all copies of the email (and attachments if any).

Qgis-user mailing list
[hidden email]
List info:

winmail.dat (44K) Download Attachment