J
Security: if you don't do stupid things like using a 512-bit RSA key, these cipher suites are all equally secure: they are all very far in the "cannot break it" zone. So that's a meh. You cannot say that one is more secure than any other.
With an exception though: the "ECDHE" suites use an ephemeral key pair for actual encryption; since the corresponding private key is never stored in a file, this grants a nifty property known as Perfect Forward Secrecy. Basically it makes communications immune to attackers who steal a copy of the server private key after the fact. PFS looks good in technical audits.
Performance issues exist only after having been duly measured. As Knuth said: Premature optimization is the root of all evil. So you should not ask such questions; you should try it out and measure. In any case, answer will depend a lot on the context: involved machines, bandwidth, usage patterns...
Short answer: won't matter.
Long answer:
The "GCM" cipher suites use GCM; the non-GCM cipher suites use AES in CBC mode and an extra HMAC (here, with SHA-384). Performance issues depend on the involved systems:
On small 32-bit systems (embedded ARM...), the MAC part of GCM will be expensive, but so will SHA-384 (because 64-bit computations...); I'd guess a tie.
On PC, AES cost will dominate;
... except on very recent PC with AES-NI, where AES is very fast, and so is GCM.
So the GCM cipher suite should, usually, be a better bargain. However, it takes a lot of bandwidth, or a very small CPU, to actually notice the difference. Even without AES-NI, a normal server has enough juice to do SSL at full gigabit bandwidth, with CPU to spare.
For the asymmetric cryptography part:
The ECDHE suites imply on the server an (elliptic-curve) Diffie-Hellman and a signature for each full handshake, whereas the ECDH cipher suites require only the elliptic-curve Diffie-Hellman, and half of that one is already done.
... But a normal PC will crunch through thousands of those per second and per code, so this very rarely matters.
... Especially since normal SSL clients reuse SSL sessions, which means that the asymmetric cryptography occurs only for the first ever connection of the day from a given client.
ECDSA signatures are faster than RSA signatures.
... Depending on key sizes, of course.
... But for verification, this is the other way round.
... And, again, it takes an awful lot of new clients per second for this to actually matter. A normal PC will do hundreds of 2048-bit RSA signatures per seconds, thousands of 256-bit ECDSA signatures per second.
ECDSA signatures are shorter than RSA signatures, so this saves a bit of network (but, again, only a few dozen bytes per full handshake).
DHE and ECDHE cipher suites also imply a few dozen extra bytes per full handshake.
DHE is like ECDHE but without the elliptic curves. You need it to use bigger mathematics to achieve the same security levels (2048-bit modulus instead of a 256-bit curve point), so it is like RSA vs ECDSA: a bit bigger, a bit slower, won't matter in practice.
So, really, you will not make a useful distinction based on security or even performance. In fact, you are already making a fashion statement, by insisting on AES-256 (instead of AES-128) and SHA-384 (instead of SHA-256). You may as well keep it on and bring it to its logical conclusion: use as much GCM and elliptic curves as possible ! This will grant brownie points from impressionable auditors.
