Have you done any analysis of where the existing application is spending most of it's time?

Well I have been told by most all is fine except the comparison that is where majority of the time is spend and this is where perl can excel.

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."

Hmmm ....

I suddenly have that magic bullet feeling

From what I've read of your problem, there may be a number of approaches.

My limited experience of C++ is that it can lead to a lot of bloat. However such code can be trimmed down to be near C-like in performance and size. I think, but I can't be sure, that this is due to the way the code is written and the way the code is built.

So has the C++ group bothered to review and trim that code?

The concept that you have been given this task just because there's a rumour that Perl is good at string comparison - without any analysis of how Perl might help being commissioned first, indicates a lack of planning somewhere in your group structure.

A manager threatening someone with loss of employment on the basis of both poor planning and exploring whether a rumour is true?

Well, these days, if I were in permanent employment, having verified what planning or assessment of the problem had taken place - and seen the supporting documentation and code to validate chasing this rumour - which in this case I'm guessing doesn't exist - my response to this threat would be to discuss the term 'constructive dismissal' with the individual concerned.

While one might elect to pursue that matter further, or might not, it may be an effective warning shot to prevent that individual putting you way out on a limb and then sawing it off at the trunk end again.