Deciding on LINQ to SQL vs StoredProcs -

while developing applications, go stored procedures contain crud logic, improve performance , maintainability. after experimenting linq sql, wondering whether, using compiled linq-to-sql queries on stored procedures improve performance?

based on comments both devslick , a1ex07, seems have fundamental misunderstanding of linq is. in order linq queries allow chaining, like

var activepeople = peoplelist.where(o => o.active).orderby(o => o.ordering).select(o => o.name); 

the execution of linq query must delayed until enumerated:

foreach(var person in activepeople) {    //if linq-to-sql, query peoplelist has waited until request database } 

this means query .where(o => o.active).orderby(o => o.ordering).select(o => o.name) not interpreted computer until point well. if run same query 100 times, means computer has reinterpret query 100 times. linq-to-sql, means translating query sql 100 times before sql sent database each time, if sql same every time.

compiling query ahead of time causes generate sql once, , use sql every time query called. has nothing stored procedures - compile query-to-a-stored-procedure in same way compile other query. asking "which gives better performance" meaningless, not mutually exclusive.

though compiling query sounds thing, in practice interpreting linq query (usually called "evaluating expression tree") takes very little time compared executing sql against database, little benefit compiling query. in meanwhile, syntax compiling query atrocious:

static readonly func<adventureworksentities, decimal, iqueryable<salesorderheader>> s_compiledquery2 =      compiledquery.compile<adventureworksentities, decimal, iqueryable<salesorderheader>>(         (ctx, total) => order in ctx.salesorderheaders                         order.totaldue >= total                         select order);  var orders = s_compiledquery2.invoke(context, totaldue); 

for reason, recommended not compile linq-to-sql queries, because ratio of code-noise-to-benefit terrible.