I don't know if there's a lot anyone can say without actually seeing the code you're working with. Are you able to post a minimal example of what you're doing that demonstrates what you'd like to solve?

Thanks for the response. Attached is the original code. I am not giving the simplified version as it will loose the prospect, since in both cases time taken will be very short to differentiate. Please ignore the code other than last two lines. XX evaluates XXXX at four points, but YY does so on 16 points in the same range of theta and phi. On my 4 core computer (Windows i7), XX takes 10 minuts, while YY takes about 3h 5 m. Once again appreciate your help

Thanks Sjoerd, I went through one of the links and tried to fix few things you suggested, changed "For" loops to "Do" and replaced the variable "K", though they did not make any major impact on processing speed. I would be thankful if you have any further suggestions. Attached is the modified *.nb file.

Also, one more doubt - If certain inefficiency in code is causing the slowness of ParallelTable process, why it is more prominent for 4X4 grid (taking > 3h) as compared to 2X2 grid (taking only 10 minutes) ?

Hi Sjoerd, I am noting down the CPU usage and RAM for each run. CPU varies b/w 58 - 67% for both 2X2 and 4X4 grid calculations. While RAM usage is stable at about 320 MB and 430 MB respectively for two cases (Total RAM of the system - 16 GB). Thanks

Hi S G. I appreciate your problem, but unfortunately I don't have that much time to spare and your code is simply quite difficult to read. The only way I could really assess the problem is by taking it apart completely and rewriting it, which is a lot of work.

However, I noticed one more thing in your code that almost certainly problematic: in the definition of XXXX there is an assignment to the function Et[m]. This function is used to define other functions elsewhere and I'm fairly certain that these assignments will get communicated back and forth between kernels. Assignments like these shouldn't be done inside of code that gets evaluated in a parallel fashion. Your code is has a slew of other side effects (meaning that non-local variables and functions are defined during the parallel evaluation) and all of them could be the culprit of poor performance.

I recommend you restructure your code to one function of phi and theta. To be on the safe side, this function should not depend on any other global variables, so every internal function should be localized with Module. So you'd end up with code that looks roughly like this:

myFunction[phi_, theta_] := Module[{
  var1, var2, ...,
  fun1, fun2, ....
},
  ...
];

In the definition of myFunction there shouldn't be any blue symbols left at the end; it should be entirely self-contained. After that, you can just call it with:

ParallelTable[{myFunction[phi, theta], phi, theta}, {phi, 0, Pi/4, Pi/12}, {theta, 0, ArcCot[Cos[phi]], ArcCot[Cos[phi]]/3}]