SQL 2014 performance

Question

We have a fresh install of SQL 2014 running on Windows 2012 R2 running in Production. 
We tested this extensively first and most of our code ran as fast as SQL 2012 or slightly better. 
Pure engine processes such as Backup jobs run about 30% faster. 
However, now that we’re in Production for the first day we’re seeing some very sporadic performance. 
For example, 90% of our jobs are running just fine.  10% of the jobs are running significantly longer. 
Jobs that used to take 7-8 minutes are now running in 40 minutes plus. 
Not only is this slowing down our server in general but it’s causing a lot of blocking issues.
We’re convinced this is a SQL 2014 issue and not hardware. 
Using iometer we can tell that this server outperforms our old server. 
SQL doesn’t always substantiate the numbers we’re seeing from iometer as far as performance compared to our old server.
We’re running on RTM, not Cumulative Update 1.
Our hardware is a beast of a server; DL580 G8, 384 GB ram, only 2 physical hard drives (running the OS/SQL) and the rest are Fusion iO cards. 
We have 9 total Fusion cards for the database, log and tempdb. 
Our old server is also a very robust server: DL380 G8, 384 GB ram, 48 physical drives and 2 Fusion iO cards for tempdb.
Has anyone else deployed SQL 2014?  Has anyone else encountered these sporadic performance issues? 
If so, did cumulative update 1 fix the issues?
Separate question: If I put my database in 2012 compatibility mode and do a backup, can SQL 2012 read the SQL 2014 backup?
Thanks in advance,
André
André

Answer 1

We applied CU2 last night.  Things seem to be better this morning but we're still seeing some differences between SQL 2012.  Here are 2 of the biggest issues we're seeing.
1 - views are slow.  We have queries that use views that are taking forever.  In some cases the view might be a simple "select 10 fields from table" type of views.  If we change our query to use the base table instead of the view, the query
finishes very quickly.  As an example, a query using the view takes 3 minutes.  If we change the query to use the base table instead of the view it finishes in 5 seconds.
2 - inner joins are slow compared to "not exists" or "exists".  Back when we migrated from SQL 2000 to 2008 we were told that joins were faster, so we migrated our code to use joins and our code flew.  Now we're seeing performance issues on some,
but not all, queries that use joins.
3 - inner joins are not able to see the outside table.  For example, this query worked just fine in SQL 2012, and it throws an error in 2014
select
top100
fromcustomers c(nolock)
inner
join(selectcorpnumber,fdate,code
fromdbo.FN_Customers_ParseCodes(c.rcode,c.corpnumber,c.fdate))r
onr.corpnumber=c.corpnumber
where
c.importtimestamp='2014-06-30
15:37:17.347'
and
c.customerid='123'
The error it throws is:
Msg 4104
,Level16,State1,Line
2
The multi
-part identifier "c.codes" could
notbe bound.
Msg 4104
,Level16,State1,Line
2
The multi
-part identifier "c.corpnumber" could
notbe bound.
Msg 4104
,Level16,State1,Line
2
The multi
-part identifier "c.fdate" could
notbe bound.
André