After reading Enabling multithreaded processing in QGIS?, I was wondering if QGIS 2.6 will include this when running various processes. I checked online and I could only find that multi-threaded rendering was introduced to QGIS 2.4 (I assume it will again be available in 2.6). Now maps can be redrawn very quickly especially when dealing with large datasets.

I read that it's fairly difficult to include multi-threading to core functionality and that users are advised to manipulate Python code in order to achieve this, such as in Parallelising GIS operations in PyQGIS?.

I also checked the feature request but it has been closed for 9 months now by Tim Sutton with the last comment being:

"I'm closing this out - Martin Dobias has an implementation in a branch which will be merged post QGIS 2.2"

Will some functions in QGIS 2.6 exploit multi-threading (or will it again be focused on rendering) and if not, will that change at QGIS 3.0?

  • Multithreading is not particularly appropriate for the majority of GIS tasks, which tend to be stream-oriented, simple, and I/O bound. The difficulty of coalescing results isn't usually worth the effort to queue them independently (vice doing the simple task immediately). The definition of "exploit" is therefore subject to significant debate. – Vince Jan 20 '17 at 15:35
  • @Vince - Thanks, I understand that multithreading is not a top priority for many use-cases. But as some work to achieve this has already been done, I was wondering if support for this (which may be a better term than "exploit") would be present in the new QGIS version =) – Joseph Jan 20 '17 at 15:45
  • 1
    @PolyGeo - Thanks, a fair point and one which is quite suitable for this Q/A format. I agree :) – Joseph Jan 23 '17 at 11:02

I think that the answer for QGIS 3.0 may be found in this recent conversation posted in Nabble:

Will Processing in QGIS 3 support parallelization?

Citing Nyall Dawson:

If you're after parallelization within a single algorithm (Eg buffering features using multiple threads) then I'm unaware of any plans in place to handle this.

  • Nice find! Although I'm a little confused with the quote which follows what you cited: "Nice and (theoretically) easy way to gain multithreaded algorithms, and it would be simple to adapt many existing algorithms to this (buffer, centroid, transform, translate, .... Basically anything which operates on each feature in isolation). ". It was my understanding that most algorithms operate on each feature individually anyway because if you don't manually select individual features, the algorithm automatically process all of them? – Joseph Jan 20 '17 at 13:54
  • I think that the quote you cited is about the possibilty of making an edit directly on the layer (instead of producing a new output): in fact, in the following he talks about the possibility of doing a buffer operation directly on the current layer, without the further processing of the returned output. – mgri Jan 20 '17 at 14:09
  • 1
    Hmm good point. I'm hoping a QGIS dev could also comment and confirm this :) – Joseph Jan 20 '17 at 14:40
  • 2
    GIS SE is not a discussion site. If you want a response from a specific provider, I suggest you query them directly. – Vince Jan 20 '17 at 15:24
  • 1
    @joseph There are many algorithms (e.g. calculating line intersections or dissolving features) where one cannot operate on individual features. – underdark Jan 20 '17 at 19:41

Rendering only at this current time (QGIS 2.6).

Martin and I have talked about some kind of generic threaded process API but it's just talks at this current time.

  • 1
    Thanks Nathan, do you personally think this venture is worth pursuing or is adding/improving functionality considered a higher priority? This is just out of curiosity :) – Joseph Oct 29 '14 at 11:22
  • It's worth pursuing, but I don't suspect it's a easy task. – Nathan W Oct 29 '14 at 11:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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