Parallel processing using NSOperation slows down application!

Question

For the "fun" of it, I'm creating a little application which matches images in iPhoto to my GPS logs (in GPX format) to geocode the photos.
Currently, I've got it to the point where it will go through my images (about 1000, but only around 250 with matching GPS data) and gets the right data from the GPX files.
The process was taking around 9 minutes to do, but with some alterations (using caching to eliminate GPX files outside the relevant date range) I've got it down to 3 minutes. The problem is that when I use multiple cores (Mac Pro 2x QX) it actually slows the process down to 3.5 minutes.
All the processors are running with 50% load (were running at 100% before my other alterations that improved performance), but analysis shows 95% of the time being spent waiting in the XQuery routines.
I imagined that this application would be perfect for multiple processors, as the matching section was processor intensive (complex XQuery expression) and appeared to be a very independent process.
The shared resources passed to the function are:
1) the path to the image being processed
2) an array of GPX files (subclass of NSXMLDocument)
Additionally, during the function it updates a dictionary related to the image (adds in the location data found).
I've tried to eliminate the block by sending a copy of the GPX array in case the system is locking access to the array (although it is not mutable) while it is being enumerated (using Obj-C 2.0 enumeration).
Can anybody give me a hint what would be causing these supposedly independent processes to be waiting? My only guess is that the XQuery library isn't thread safe, but can't find confirmation.
Memory usage is being kept low, and there aren't any page swaps showing up.
Thanks.
Ray.

Answer 1

etresoft wrote:
Ray A wrote:
Each photo is independent of the others, so I can't see any reason why multiple images couldn't be processed simultaneously.
But there is only a single disk where all these images reside. But then, you said there was no disk activity. How are you accessing these images?
I was a little inaccurate with my earlier posts. The images I speak of are at this stage is just the iPhoto albumdata.xml file, from which I obtain the date information for the image.
The iPhoto file is read into memory and decomposed into the array of image data, from which the date is obtained and passed through to the xQuery methods.
Perhaps not processor intensive (in terms of performing calculations) but reading from memory and comparing.
Read from memory into where? Either it is on disk and you have serial access only or it has already been read into RAM.
The GPX files are read into memory (i.e. RAM) when the programme launches, and converted into NSXMLDocuments. So there will be lots of memory access, but not disk access.
As mentioned earlier, I've duplicated the array containing the files… (+realisation happening+)…
Perhaps it is access to the NSXMLDocument files that is causing the lock. I've duplicated the array, but not a deep copy down to the actual XML objects. I'll see if that makes a difference.
You shouldn't have to do even that. If you are just querying, there is no modification needed. They can all share the same data.
That's what I figured too, especially since it is not a mutable array. I didn't have any luck with deep copying as my first attempt caused the programme to run out of available memory.
But in reply to your question, when running as a single thread the bottleneck is also the XQuery execution. It takes about 1 second to execute a query on each relevant GPX file for a match. About 10 seconds when done in parallel! :-o
How big are those files? How many GPX files do you have.
Will have around 100 when it's running properly, but at the moment I'm using about a dozen. Each file is around 1MB.
I would think you could merge all the data from all the GPX files first. Then start one thread to go through all the image files and pull out the search values and put them into a queue. Then have all the cores create an operator and grab a data element from the queue to process.
My initial thought was to simplify things by merging them all, but the issue with that is the computer would need to scan one huge file for each image, rather than being able to omit the individual files that fall out of the date range relevant.
Or, you could swap the problem space axes. You could divvy up the GPX data between all the cores. Then, for each image, look for a match in each subset - there should be only one. If NSXMLDocument is the bottleneck, this would solve it.
May not be effective as it's only the relevant GPX file that takes a long time. The rest of the files are checked against to see if they cover the date in question, and skipped if not. Images without GPX data for their date (most of them since I'm using a test set of GPX files) get processed in the blink of an eye.
But I appreciate the effort you're putting in to come up with possible solutions.
While I'd like to know the reasons it's not working, I've got it to the point where it's processing images (with matching GPX files) in less than half a second on single thread, and putting the whole matching routine in separate thread has given me UI responsiveness. So if gets no better, at least the user (i.e. me) is kept entertained by the feedback while it runs.
Ray.