Very few SQL language features are different between editions.
Some language constructs (CREATE PARTITION for example and related) are additional (as opposed to different) and won't work because these are Enterprise features.
However, for day to day code, nothing special, things are almost identical.
The only thing I can recall that is different is how indexed views are used
There are some underlying performance enhancements in filestream and full-text search. I don't have the details handy. I am also sure there are other underlying enhancements that aren't publicized, as well as fixes from 2008/R2 that made it into service packs and cumulative updates on those platforms that were ported forward into SQL Server 2012. That would be a bit more quiet because while 2012 was in development there wasn't a need for a public KB article for every change.
Some of the new windowing functionality will make calculations like running totals perform way better. And OFFSET can be used to make child's play out of things like calculating a median. FORCESEEK also allows you to now actually specify the index you want used, instead of taking whatever SQL Server thought you meant. But those require code changes.
There is also going to be more predictable performance with regard to memory use - the memory manager now handles more than just single-page allocations, so "Max server memory" has a much more accurate meaning than it has in prior versions. Resource Governor memory settings also take advantage of this, and can be used for scheduler/NUMA affinity as well.
Troubleshooting performance is also a lot easier. For example there is a lot more information included in execution plans, and extended events has almost full parity with trace (and adds much more powerful causality tracking).
I was surprised that they didn't publish TPC stuff well in advance of the release date (not that those tests really represent real-world stuff, but it's fun to watch the "my dad can beat up your dad, at least today" arguments unfold between the vendors). Glenn Berry blogged about one of the SQL Server 2012 TPC-E results. I apologize but I don't have time to investigate whether there is an easy way to compare this apples to apples against similar benchmarks using 2008 or 2008 R2. The problem with aged benchmarks is that they're never on the same hardware, so while the new benchmarks are always faster (or else they won't get released), it's impossible to tell how much of the improvement was based on the hardware and how much on the software.
Your best bet is to install SQL Server 2012, restore a copy of your database, update compat level, update statistics, and run your worklaod on your hardware using your data.
Best Answer
The odds are that on the restore, it is appropriate to update statistics on the db. In many cases, this step alone will help.
If it does not help, it may be that index fragmentation crept up and became an issue now, though my $ is on statstics...