Side note:My actual comment starts below in the next paragraph, I tried to add just a comment to the answer above me related to the statements about the speed of the == versus .equals() methods but I need 50 points to comment yet I'm allowed to answer, even though my answer which is related to the other answer would be much better as an 'in thread' comment. Regardless....
As Adrian I'm sure knows, you need to be very careful when doing performance comparisons as a lot of things can affect the timing, from methods not being 'warmed' up, to incorrectly setup performance tests, to timing the wrong thing and inadvertently timing other functionality beyond what you thought.
As an example I ran the exact same code above (for the .equals()/.equalsIgnoreCase()/== timings) a total of 50 times to try and get an 'average' value (for some form of average). After 50 runs of each of the 3 tests and with each doing 100,000 loops per for loop I ended up with times for the .equals() and .equalsIgnoreCase() methods that are within a few percent of each other so for simplicity here I'm treating them as the same and showing the average value for them.
.equals/.equalsIgnoreCase = ~815ms (ranging in tests from 650 to 909)
using the 2equal signs == = ~467ms (ranging in tests from 350 to 838)
So the performance timings I get (after a total 50 test runs) indicates about a roughly 75% improvement using the == over the .equalsIgnoreCase() however that is a long way away from the 700%/7x mentioned above.
Also, I've put the min and max times that I got next to each of the times as well as this just goes to show how inaccurate/variable the performance timing testing can be. Although there was roughly a 75% improvement on average using '==' in some tests the times could vary so much that it would actually be slower than the .equalsIgnoreCase() methods.
Further, I was running 5 lots of the 3 tests each time and collecting 5 lots of 3 sets of values after every run. If there was load on my laptop during these test runs it could greatly effect the times and cause a time on one/many of the test cases to blow out greatly. To try to minimise this I would have no other apps/programs/tools running/processing at the same time and once the test was started/running I would not move the mouse, click, perform any kind of input until the test completed. I also decided that as part of my methodology that if even a single test case blew out in terms of time because of load then I would completely exclude ALL 5 sets of 3 test results in that run and re-run. In some of these test runs where there was load on the laptop during the test runs I would be getting times of 1000, 2000, 3000ms and more which was multiple times above the final averages.
So, to sum up, what I'm trying to get at is that performance figures need to be carefully obtained and handed up with a large number of caveats usually. I do agree with Adrian in that the '==' method of comparison of Strings in Apex is actually quicker although perhaps no where near 7 times faster but somewhere closer to less than twice as fast. It also gives you null safety in situations like:
String a = null;
String b = 'foo';
System.debug(' a==b =' + (a==b)); // false
System.debug('a.equals(b) =' + (a.equalsIgnoreCase(b))); // Null Pointer Exception
System.debug('a?.equals(b)=' + (a?.equalsIgnoreCase(b)));// null