The most robust way of answering this is to benchmark it. Failing
that, there are several things to note (roughly in order of
importance).
First, the most cheap floating-point operations on a modern CPU are
addition and multiplication (both are equally fast; same as fused
multiply-adds when available). Division is much slower (by a factor of
~20), trigonometric functions are also slower (~200), square roots and
logs similar. In fact, sometimes (depends on architecture) trig
functions, roots, logs are implemented in a library. The best
reference for this is usually the optimization guide published by the
whichever company made your CPU. So as a rule of thumb you want to
minimize special functions first, then divisions, then multiplications
and additions.
So by this measure the second formula is much worse: the there is one
inverse trig function, one square root (it would be wasteful to
implement your formula as written, with three square roots), and one
sincos (since they are expensive it is better to evaluate sincos once
and then write things like $\tan\frac\theta2$ in terms of those). Your
first formula involves the other special functions, apart from sincos,
only once at the end.
Second, you should not stop at Newton's method. For example, if you
compare Newton's method with Halley's method,
$$ \frac{e \sin (x)-e x \cos (x)+M}{1-e \cos (x)}, \qquad
x-\frac{(e \cos (x)-1) (e \sin (x)+M-x)}{e^2+e (M-x) \sin (x)-2 e \cos
(x)+1}, $$
both evaluate the expensive trigonometric functions at the same
arguments, but with a little more algebra Halley's method can converge
faster; the extra algebra might not outweigh the savings of
evaluating trigonometric fewer times. So Halley's method (and other
iterative methods) also need to be checked.
Third, you can precompute some things. For example, if you start by
reducing the argument to the range $0<E<2\pi$, you can experimentally,
in advance, find the maximum number of iterations taken by the
method. Since the number of iterations is fairly small (depending on
precision) and mispredicted branches can be expensive, it may also
make sense to unroll the iteration loop by hand to a fixed sufficient
number of iterations. Unrolled code can also more easily benefit from
vectorization.
Fourth, it is difficult to intuitively predict which optimizations
will do the best. And since this is just one fairly simple equation,
it is probably best to benchmark many different approaches and find
the best. When doing this, also consider what optimization flags your
compiler supports for floating-point arithmetic (some of them are
interesting and important, many people know about -ffast-math
, but
it actually decomposes into different helpful or harmful optimization
flags; here is gcc's
list for example). Another thing to do is to look at the assembly
output of your compiler to see which CPU instructions it actually ends
up using.
Fifth, if you need to solve this equation many times for the same
eccentricity $e$, it is possible to rewrite the problem. If you
consider the function $E = E(M)$, on the range $[0,2\pi]$, given by
the solutions of the equation for fixed known $e$, you can approximate
the function $E(M)$ using, for example, Chebyshev series, which takes
only a small number of evaluations of $E(M)$ (which can be done with
any root-finding method). Once you have a sufficiently close
approximation, which might be a 20-term Chebyshev series or something
like that, you can evaluate that later without needing to solve the
equation again.