Two things will provide for immense speed-up with parallel functions like ParallelTable:
Launch your kernels ahead of the initial parallel call with:
LaunchKernels["Number of Kernels, max available if left blank"]
Ensure each kernel has prior knowledge of the functions with:
DistributeDefinitions["context`"]
You should also see some increase in speed, due to a decrease in CPU need, if you were to provide assumptions for all of your defined variable functions. What I mean by this is something like:
f[x_?NumericQ,n_?IntegerQ]
Wherein x is always a numerical input and n is an integer.
I hope this helps you understand how to run parallel code better, it's a constant learning process, as we will continue to make more and more efficient ways that leave the previous best methods in the dust, and we will have to keep up :D
So, after discussing with @happy fish, I was able to test the code, and got this output, after replacing the second ParallelTable with Table:
{-0.463029, -0.463029, -0.463029, -0.463029, -0.463029, -0.463029, -0.463029, -0.463029, -0.463029, -0.463029}
There is something amiss with this, and I apologize that I cannot immediately parse what the issue is. I will take some time to check later and see if I can provide additional input, after satisfying my own duties prior ;) As for the rest:
The issue with using two ParallelTable calls is why you would not receive output for your addition of Parallel to the second Table, again, barring my lack of understanding. Additionally, you would assuredly benefit from a functional method of implementing this code. There are numerous inline reassignments which can likely be shortened, and I anticipate that is another issue imparting itself upon your long-running/non-functional parallel implementation.