How quickly can we find a prime at least as great as $n$? This may be trivial, but I'm wondering a few things.
Is there an easy way to find a prime of the form $2k+1>n$ for some $n$?
EDIT
How quickly can we find a prime greater than a given number $n$?
 A: There is no proof, but for all known $n \geq 20,$ there is a prime $p$ with $$ n < p < n + \log^2 n. $$ Here the logarithm is base $e \approx 2.718281828459.$
I would say the quickest way to find a prime is to do a part sieve of Eratosthenes (spelling??) for multiples of 2,3,5,7, 11 between the given bounds. Test the survivors for "probable prime" status. Test the survivors for prime certificate.
If you are going to do this for real, you do the sieve for some collection of smaller primes that you have saved up. For comparison, when Mathematica first wrote their integer factoring, they did trial division by primes up to 46340, these having been saved in some sort of list. The relevance of the bound is that $$ \left\lfloor \sqrt {2^{31} -1} \right\rfloor = 46340.$$ So, that was a good bound for the purpose. If you are going to write your own nextprime function, you save a list of primes up to some bound, based largely on the size of the numbers you are using and the likely prime gap. At some point, throwing in more small primes amounts to diminishing returns, as far as execution speed.
see Prime pair points slope approaches 1 for a whole bunch of data about prime gaps.
A: All but one prime is of the form $2k + 1$.
As far as finding them, some common tests would be Rabin-Miller or AKS, which runs in polynomial time. Since the density of primes around $n$ is "roughly" $\frac{1}{\ln n}$, a prime will be encountered fairly quickly, on average - a few thousand tests for numbers on the order of $10^{100}$.
Of course, Bertrand's Postulate gives a strict upper bound on how many numbers would need to be tested.
A: As noted in other answers, you should encounter a prime rather soon after $n$ compared to how big $n$ is.
To find one as "quickly as possible," the ingredients proposed in other answers are key but it's worth noting some  attention to detail.
When you first apply the sieve, then you need to decide how many of the initial primes to use for your sieve.
In general, if you apply the sieve with base prime $p$, then roughly $1/p$ of your remaining prime candidates will be removed, and running the sieve with one base prime is much faster than a single Rabin-Miller or AKS test if you are starting with a range of possible primes of size $O((\log n)^2)$.
So as $n$ gets larger, you should run the sieve with more base primes, and probably you want to use at least a couple hundred base primes for the typical large $n$ encountered in large primality testing.
Also, after the sieve, when you run Rabin-Miller for probable primality testing (which is much faster per iteration than the guaranteed primality testing of AKS), if you want to have an overall algorithm which is almost always as fast as possible, then you want to run AKS one time and almost be guaranteed the answer will be "prime," so you want to run Rabin-Miller for a decent number of iterations (like at least 10) on a candidate prime number while the test still says "probably prime," and then there will only be a $1/4^{10} = $ roughly one in a million chance that your number is not prime if it passes these 10 Rabin-Miller iterations, so it's almost guaranteed the number is prime, in which case you only have to run the slow AKS primality checking once to get your prime. 
Also note it doesn't make sense to run Rabin-Miller iterations in round-robin fashion on the entire set of numbers you are considering as candidate primes after the sieve; it can be more efficient to just test candidate numbers one-by-one with Rabin-Miller, repeating Rabin-Miller iterations on the same number either until you get an iteration that says "not prime" or you get 10 iterations in a row that say "probably prime." 
If a number is not prime, the average number of Rabin-Miller iterations you have to run to determine this is less than 2.
