17

Ok I am not a programmer but a prolific GIS user. I know that QGIS is written in C++ and ArcGIS in ??? but for most of my tasks lately I always try to use QGIS not only because it is free but due to the fact that its User experience is so good.

All the GIS Gurus out there can you tell me some reasons for the difference in speed between these two systems? Honestly it pains me to use ArcGIS 10 due to its speed and I have a PC with 8 GB RAM.

Improve this question
8
  • 3
    Can you provide more information on which aspects you're finding slow? Eg, browsing for data, analysing rasters, geoprocessing, etc?
    – Stephen Lead
    Commented Feb 16, 2012 at 7:42
  • The general experience is very slow ..i mean adding shapefiles...opening arctoolbox etc
    – GeoH2O
    Commented Feb 16, 2012 at 17:15
  • 2
    ArcGIS is definetly not written in .NET. It is mostly written in C++ with a lot of other stuff bolted on...
    – Devdatta Tengshe
    Commented Feb 17, 2012 at 2:10
  • 1
    @StephenLead, I've clocked ogr2ogr at 36 times faster than Arcgis when converting shapefiles (ref). I expect QGIS would be a little bit slower than barebones ogr2ogr at the same task, but not by much since it uses ogr (evidence either way is welcome).
    – matt wilkie
    Commented Feb 21, 2012 at 21:15
  • 3
    perhaps conversation re: specific speed differences could be carried on elsewhere, perhaps chat? chat.stackexchange.com/transcript/message/3510767#3510767
    – matt wilkie
    Commented Feb 21, 2012 at 21:58

6 Answers 6

Reset to default
12

I'm not that familiar with QGIS, but I wonder how it compares with ArcGIS in terms of extensibility. Unfortunately there seems to be at least some tradeoffs between extensibility and performance. The best way I've found to get a feel for ArcGIS extensibility is to take a look at Esri's COM component categories found in the registry.

Each category represents a place where users can register dlls containing classes that implement an Esri interface. There are a lot of categories. These categories also contain dog food - Esri uses them not only to discover 3rd party customizations, but also out of the box functionality. While this provides a very fine-grained level of customization, it also means that all these fine grains need to be discovered and loaded at run time. I'm not sure what the relocation cost is, but it must be significant.

enter image description here

C:\Program Files (x86)\ArcGIS\Desktop10.0\Bin\Categories.exe

When you create a dll in Visual Studio there is a place where you can specify the base address for the dll to load into. Since there are so many dlls of different sizes being loaded knowing this ahead of time for an ArcObjects customization would be very difficult. Still, I wonder if a config file could be created instructing where the dll should be loaded into memory. If so, once a user has arcmap running with the dlls loaded that he will typically use he could run a routine that would write the dll base addresses to a config file. That way when arcmap starts it could avoid relocation by loading into those addresses. Then again maybe with 64 bit this won't matter.

At 10.0 Esri introduced Add-ins. The categories of add-ins is much smaller, and discovery doesn't rely on the windows registry. Instead, the add-in dlls are zipped up and placed in a known folder. I'm not sure how this compares performance-wise with dlls discovered via the windows registry. I think the main goal was to allow installation by non-admins.

I'm assuming the question is referring to the Desktop product. The new ArcGIS Runtime product is much lighter weight. I've heard it described as a replacement for MapObjects. It will be interesting to see how it evolves. If Esri does introduce extensibility for WPF Runtime, I hope they don't use the same mechanism for discovery used by Visual Studio when it populates the list of assemblies. That first time clicking "Add Reference..." has gotten painfully slow.

Improve this answer
5
  • 3
    I was told by an Esri sales rep a few years ago that Esri has the largest COM library on earth, easily larger than anything even Microsoft had built. I've assumed since then that part of the sluggishness of Arcgis Desktop is loading all of that library at once rather than just grabbing the bits and pieces needed on demand.
    – matt wilkie
    Commented Feb 21, 2012 at 22:13
  • @mattwilkie The startup time for ArcMap used to be much slower. To improve it they introduced just-in-time extensions. I'm not certain, but I think a similar approach is taken with gx objects that get loaded when you fire up the add data dialog the first time.
    – Kirk Kuykendall
    Commented Feb 21, 2012 at 23:10
  • hmm. Startup time is not faster for me (granted I'm going from memory, not data, so it could be just perception). 17s from clicking Arcmap 10 button in Taskbar until it's ready to do something (with the "load last map" wizard thing turned off). 2nd session is about 12s. This is after replacing the C: hard disk with an SSD. Quantum takes 4s for first run and 2s for next.
    – matt wilkie
    Commented Feb 22, 2012 at 17:03
  • @mattwilkie Yeah, at the same time they've added new toolbars etc., so any performance gains from just-in-time likely have not completely compensated for delays resulting from new software features. Also other factors to consider: Is it accessing a license server? How much RAM? Is it faster if you delete/rename your normal.mxt? (test second time after deleting it since first startup will take time to re-create it) Have you installed customizations?
    – Kirk Kuykendall
    Commented Feb 22, 2012 at 17:16
  • 1
    Kirk: great answer. @mattwilkie: it is true. Ms Office had, at one point, around 400 (+?) COM Objects. I think by now, the GeoDatabase by itself has that many. Truth is that for better or for worse, ESRI went a bit COM crazy. I think for the time, it was a safe sound decision.
    – Ragi Yaser Burhum
    Commented Mar 23, 2012 at 5:06
11

ArcGIS seems very bloated. I remember a huge performance hit when migrating from Arcview 3.2 to ArcGIS 8.0, and in a lot of places it still exists. At that time I thought it had a lot to do with ESRI migrating earlier Arc/Info code to Windows and having to cut some corners in performance, but I'm not sure if that's true. I recall seeing some examples on this very site about functions that are still dramatically faster in Arcview 3.3 than ArcGIS 10. This has nothing to do with startup times, etc. And I disagree with the previous answer than it has to do with 'user skills'. Clicking and waiting has nothing to do with skill.

I think the reality is that ArcGIS was not written with performance in mind and each version keeps attempting to toss more and more functionality onto an already overloaded code platform.

Improve this answer
9

Forgive me for resurrecting the thread, but I can give a specific example of how the user experience differs for ArcMap and QGIS.

Today I needed to build a point grid with 250 meter spacing across a small country, clip the point grid to a country border polygon, and associate the values of several rasters to the point grid.

In ArcMap, this took me about 10 minutes, from downloading the data to a finished dataset. In QGIS (Wroclaw), The program crashed twice just clipping the grid with the polygon, then ran for an hour before completing on the third attempt. THis is on a box with 4 dual-cores and 6Gb RAM.

I love QGIS, and it irks me to use ArcMap, but I find lots of common use cases where QGIS doesn't meet my needs.

Now, if anyone has any performance tuning advice that could resolve this performance gap, I am all ears.

Chris

Improve this answer
4
  • agreed but for what it is worth i always flock to QGIS first and if it does not work there back to ArcGIS
    – GeoH2O
    Commented Mar 23, 2012 at 5:01
  • 1
    Sounds like a bug to me. Crashes is not a measure of bad performance but a symptom of something wrong. Report it to QGIS people
    – Nicklas Avén
    Commented Mar 23, 2012 at 15:24
  • For how big an area are you building this point grid? Just ran the same type of operation on 57k points in QGIS (1.9) without a problem.
    – Simbamangu
    Commented Mar 23, 2012 at 17:42
  • @Simbamangu this was for a bounding box around Honduras -- roughly a half-million points. at Nicklas_Aven: Point taken; if I have time to reproduce reliably I will submit.
    – iamchriskelley
    Commented Mar 23, 2012 at 18:12
6

I do not think that Arc is written in .NET. Arcobjects are written in C++. Arc may be slower due use of many advanced GUI's, help tools, add-ons etc. QGIS is great software but it lacks some useful features that may be good for beginners. Also I do not think that basic lavel tools in ESRI (Arcobjects) are slow. It usually comes down to user skills, if user know how to use Arc, it is not that slow at all. Having said that, I should mention also that every tool should be considered on case by case basis regarding its performance. The other thing is that, Arc was first on the GIS scene. First (relatively to QGIS) is always with bugs and next generation is a bit better, in this case faster, but all this is just my personal opinion.

Improve this answer
3
  • 2
    Sidenote: I suspect that at least parts of ArcGIS' core are still written in Fortran (which is rumoured to be as fast, if not faster than, C for certain numeric tasks): If you run a .NET console application that makes use of ArcObjects, and you press Ctrl+C while an ArcObjects performs some operation, you will get a message from a Fortran runtime library.
    – stakx
    Commented Feb 16, 2012 at 8:45
  • 5
    Also without going into the nitty gritty details, ArcObjects is based on COM, one of the early interoperability frameworks, and has its own performance burdens especially when marshaling between managed (e.g, .NET) and unmanaged (C++) code.
    – blah238
    Commented Feb 16, 2012 at 9:15
  • 4
    @stakx There's overhead in that Fortran code, at least on the raster side (Spatial Analyst). I have developed Fortran add-ons to SA and found they always ran at least five times faster. Over the years, the layers of wrappers on wrappers on wrappers that have been built to integrate the original (vintage 70's and 80's) code have created a growing burden on Arc* performance.
    – whuber
    Commented Feb 16, 2012 at 15:59
6

This relates to ArcGIS performance: ArcMap, ArcCatalog very slow to open on new laptop with ample resources? which may in part account for some of the performance issues. That thread shows how hardware, network, and licensing configuration can have a substantial effect on ArcGIS performance. Possibly, some of the reported differences in speed could be due to such factors rather than inherent differences in capabilities.

(Posted as an answer link, since comments tend to get lost.)

Improve this answer
2
  • 1
    Replies and comments have different purposes here, Dan. You're right, comments have a second-class status. One reason is to emphasize genuinely helpful answers. Anything that isn't an answer should be an effort to make a question answerable or to improve a question or answer: that's a comment, even when it's truly brilliant.
    – whuber
    Commented Feb 17, 2012 at 0:03
  • Agreed the version in our labs work better than the trial version i am running on my PC...
    – GeoH2O
    Commented Feb 17, 2012 at 1:02
2

I work with enterprise level data (point of interest data for whole Turkey for example) and sometimes just to check dataset, I need that rendering.

If you want to improve your performance with ArcGIS, there are few things that I could advise;

Always use projected data. Use geodatabases or ArcSDE with postgresql works perfect for me.

Using file geodatabase and if possible arcsde increases the speed of your operations. My personal experience with QGIS and ArcMap is actually the contrary. As It takes almost minutes to render 3 million points on a map. On the other hand ArcMap renders them within seconds.

Just my opinion.

Improve this answer
1
  • Why render 3 million points? If you mean that the layer has 3 million points and some of them is in your view, that is fast in QGIS too, but you will need a spatial index. But I agree that QGIS can be quite hard to stop when you do the mistake of trying to render too many geometries. Even when killing the rendering with esc the already rendered geoemtries sometimes hangs there.
    – Nicklas Avén
    Commented Mar 23, 2012 at 8:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.