Select with EF is always slower than with Linq2SQL

This is only true when you leave the default value of ObjectQuery.MergeOption or set it to any other value but MergeOption.NoTracking. However, if you do set this value to MergeOption.NoTracking, a select will be 3 times faster than with LINQ2SQL.

The following table compares various scenarios:

So what you see here is that EDM is the fastest access after DataReader, but also the slowest if tracking is (by default) enabled. Depending on what you do, you might consider to disable Tracking for faster read access, but with the possibility of redundant data in memory.

Linq2Sql supports MS SQL only

This is not really true! Though there is currently only one IQueryProvider for MS SQL, but who prevents other SQL Provider to implement their own IQueryProvider? For instance, Oracle offers native DbConnection, DbCommand and DbReader, why not a QueryProvider?

EDM does not support UDF (User defined Functions)

Unfortunately, as with .NET 3.5 SP1 this is true. Though you can currently describe a function with

where it differs from a stored procedure by IsComposable set to true instead of false, there is currently no support for it. Usage of UDF with EF is announced to be available with .NET 4.0

Linq2SQL can do everything that EF can do and more

No. There are some features that is currently not possible with EF, but there are also features in EF that is not available with Linq2SQL.

• EF is significantly (>300%) faster in writing and updating data back to the database
• EF supports n:m relations which Linq2SQL doesn't
• Linq2SQL supports contains in query, while EF (currently) doesn't
• Linq2SQL supports UDF, EF doesn't (with Framework 3.5SP1)