Well. If my job was on the line, the first thing I would do is ensure that Perl can perform the comparison more quickly than the existing C++ code.

Get hold of the most complex set of data for comparison and stick it (them? whatever you are comparing it against) in a couple of files and build a C++ exe that calls the existing comparison function to get a base timing. Then write your perl equivalent and see how it compares.

Unless you can achieve some significant savings in the most expensive area, there is little chance of you achieving anything worthwhile by just porting the application from C++ and forks to Perl and threads.

well that is the first thing that i had asked .. but getting help from the current dev ( with there on work pressure) is the first risk.Infact i had made a simple script that would fire and compare but i could not get a replica in C++ and so couldn't compare.

The only way i think i can beat the current app is by doing things parallely.

Well i can fire max 20 query processes/Threads and get response from the app server parallely.If i can find a way to do comparison parallely i think i can win.That is why i thought of the queryBoss/queryWorker and compBoss/compWorker concept.The queryBoss would launch X no of queryWorkers and they start quering dequeing the query from the threaded queue.They also do the first level of comparison ( string compare of both the results).if this comp fails they dump the results in prod and test file and store the name of the files in a Global threaded Queue.The compBoss if blocking on this Global Threaded Queue containg file names.As soon as it is able to dequeue an object that is defined it launches X no of comp threads with Global Threaded Q's object as a parmeter.It enqueues the object again , one that it had dequeued to come out of its blocking state.Each compWorker dequeues the object and starts comparing the files