[GIS] How to improve multi-core processor utilization % in Mapinfo

mapinfo

What would be the best way to get large tasks to run in MapInfo without booking all afternoon for a few split and merge queries? I have two quad-core processors in a Win7 machine, but mapinfo will only use a single core, 13% of my total processing power.

Is there any way to get MapInfo use multiple cores, or just to use more of my processing power?
If not, do other packages like QGIS or ESRI work better?

I work with very large polygons where most tasks are scripted and scheduled overnight. When I'm asked a non-standard question (Like right now) I spend an hour+ on every step. Is this just my penance for having a very simple file structure with very large files?

EDIT: In the future, I would make a few copies of my input files and try running multiple parts of the query on the different sets of files in different MapInfo instances, as per Peter's suggestion below. I would also probably use 'Enclose' to get the extents of my polygon files rather than 'Joining' all the often overlapping files together to get information about area, and at the same time run a parallel MapInfo instance for separate queries about population and then join the output at the end stage.
However, this is only a partial solution, as I would still like faster processing in order to be able to try and fail quickly, and to get an output in a reasonable time no matter how silly and inefficient my workflow is. And a pony too, I suppose.

Best Answer

Update: MapInfo Professional 12.5 now has multithrading support, see further details in the end of this answer

Yeah, your are right.

Currently MapInfo Professional will only use one of your many cores at a time. This is on our longer term plan to be fixed. We are not planning on making MapInfo Pro completely multi threaded. Instead we plan on looking at specific task that users tell us are slow and would make good sense to make multi threaded.

In case you haven't seen, we put out a survey a week ago regarding YOUR requirements for the next version of MapInfo Pro, not 12 but 12.5, planned release summer 2014.

You can find the survey here: MapInfo Pro Survey

What really could be helpful, is for you to tell us what tasks you currently are trying to do and maybe even supply your datasets. If you have scripted your tasks it's even better.

Any way back to your question: One way of making MapInfo Pro multi threaded is to launch more instanses of MapInfo Pro. So if you in some way can divide your tasks into smaller pieces, you could launch as manu instances of MapInfo Pro and let each instance take a hit at a smaller piece of the overall task.

There are a few tricks to speeding up processing in MapInfo Pro. These do however depend on what you are trying to do. It could be things such as:

  • Adding index to certain columns
  • Removing index on your columns

    Drop Index MY_TABLE(MY_COLUMN)

By dropping any indexes on your MapInfo table, MapInfo Professional doesn't have to spend time updating these when you insert new records into the table. You can drop the index, do your work on the table and when done, recreate the index again.

  • Setting your table(s) in fastedit mode

    Set Table MY_TABLE FastEdit On Undo Off

Byt turning on FastEdit on your table, MapInfo Professional will not create a set of transaction files for your table. But also note that when you put a table into FastEdit mode, you can't undo/revert your changes. Therefor be careful and consider creating a backup of your data.

  • Packing your tables

Could you give us a few hints to what your currents tasks are doing?

With the release of MapInfo Pro 12.5 in June 2014 Pitney Bowes have taken some great steps to improve performance. We now support multi threading for these four object procession methods:

  • Buffer
  • Split
  • Erase
  • Erase Outside

More will come in the coming releases

In the end of November Pitney Bowes will release a full 64 bit version of MapInfo Pro 12.5 that can take advantage of more ram. Even thought we haven't changed any features, yet, to explicitly take advantage of more memory we still do see a performance improvement in certain functions.

Related Question