Re^19: Problem in Inter Process Communication

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.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re^19: Problem in Inter Process Communication

Replies are listed 'Best First'.
Re^20: Problem in Inter Process Communication by libvenus (Sexton) on Aug 22, 2008 at 18:01 UTC
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	[reply]

Replies are listed 'Best First'.

Re^20: Problem in Inter Process Communication
by libvenus (Sexton) on Aug 22, 2008 at 18:01 UTC

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

[reply]