Entity Framework: What does Stored Procedure provide for us?

I keep thinking about what the stored procedure can do for our applications in EF?
. SP execution efficiency
I have seen the performance analysis report of the ado.net team on EF and the comparison of the performance of the LINQ to entity, esql, and SQL statements,
ADO. NET Entity Framework Performance Comparison

Exploring-the-performance-of-the-ado-net-entity-framework-part-1.aspx
Exploring-the-performance-of-the-ado-net-entity-framework-part-2.aspx
In Article I have seen a lot of affirmation and tolerance in the comments. there are also information about the performance of the stored procedure. so I compared the Stored Procedure SP with the LINQ to entity a few days ago, the specific method is to use SP and LINQ to entity to query the time when the order object with orderid 10248 is repeated for 100 times. test the stored procedure call Code :
Using (northwindefentities context = new northwindefentities ())
{
Start = datetime. now;
For (INT I = 0; I <100; I ++)
{
Orders order = context. getorder (10248); // a single entity order with part property}
End = datetime. now;
Usage = end-start;
Console. writeline ("SP query with all properties 100 time's usage: {0} milliseconds", usage. milliseconds );

}
187 MS was used in the first test, and the subsequent test time was 171 Ms.
Code for testing the function:
Using (northwindefentities context = new northwindefentities ())
{
Start = datetime. now;
For (INT I = 0; I <100; I ++)
{
Orders order = context. Orders. Where (q => q. orderid = 10248). firstordefault <orders> ();
}
End = datetime. now;
Usage = end-start;
Console. writeline ("LINQ to entity query 100 time's usage: {0} milliseconds", usage. milliseconds );
}
The time used in the first test is 859 ms, and the subsequent test time is 843ms. I would like to compare the performance of the stored procedure to be obvious now. Both of them need to be interpreted, and then the corresponding SQL is generated. after all, SQL is directly used to use stored procedures in EF.

. Solve the big entity (Big Data) Problem
In OO, processing big data becomes a headache, because operations on big data are more likely to become the whole application. Program Performance bottleneck. an entity object that is very heavy in the business (High Access Frequency) and extremely important does not need to process every attribute in the business processing of the application, some attributes are processed in different application modules. Therefore, in this scenario, we will frequently retrieve the entire object from the database to process certain attributes, which is obviously a waste of behavior, EF cannot avoid this situation. this problem occurs in projects I participated in. A business entity object has more than 100 attributes and more than 20 associated objects. Fortunately, EF does not allow implicit loading of associated objects, otherwise, it is a complex action to retrieve an object each time. however, during my previous exercises on EF extension, I was thinking that using SP may solve this problem. SP returned the attributes to be processed, and passed the materialized attributes (materializer) the result is to retrieve the attributes that we need to pay attention to. The attributes that do not need to be followed are null. in order to confirm the possibility of such an idea, I also made a test: retrieve the five attributes of order.
Private Static readonly materializer <orders> s_ordermaterializer = new materializer <orders> (r =>
New orders
{
Orderid = R. Field <int> ("orderid "),
Employeeid = R. Field <int> ("employeeid "),
Orderdate = R. Field <datetime> ("orderdate "),
Shipcity = R. Field <string> ("shipcity "),
Shipregion = R. Field <string> ("shipregion "),

});
Private Static readonly materializer <orders> _ ordermaterializer = new materializer <orders> (r =>
New orders
{
Orderid = R. Field <int> ("orderid "),
Employeeid = R. Field <int> ("employeeid "),
Orderdate = R. Field <datetime> ("orderdate "),
Requireddate = R. Field <datetime> ("requireddate "),
Shippeddate = R. Field <datetime> ("shippeddate "),
Freight = R. Field <decimal> ("freight "),
Shipname = R. Field <string> ("shipname "),
Shipaddress = R. Field <string> ("shipaddress "),
Shipcity = R. Field <string> ("shipcity "),
Shipregion = R. Field <string> ("shipregion "),
Shippostalcode = R. Field <string> ("shippostalcode "),
Shipcountry = R. Field <string> ("shipcountry ")
});
The following is the test code for the above extended code:

1 Orders order = Context. getorder ( 10248 );
2 System. reflection. propertyinfo [] Properties =   Typeof (Orders). getproperties (system. reflection. bindingflags. Public | System. reflection. bindingflags. Instance | System. reflection. bindingflags. declaredonly );
3
4 Foreach (VAR pro In Properties)
5 {
6 Object O = Pro. getvalue (order, Null );
7 If (O ! =   Null )
8 Console. writeline ( " {0 }:{ 1} " , Pro. Name, O. tostring ());
9 Else
10 Console. writeline ( " {0 }:{ 1} " , Pro. Name, Null );
11 }
12 Context. Detach (order );
13 Console. writeline ();
14 Orders Order1 = Context. getorder1 ( 10248 );
15 System. reflection. propertyinfo [] properties1 =   Typeof (Orders). getproperties (system. reflection. bindingflags. Public | System. reflection. bindingflags. Instance | System. reflection. bindingflags. declaredonly );
16
17 Foreach (VAR pro In Properties1)
18 {
19 Object O = Pro. getvalue (Order1, Null );
20 If (O ! =   Null )
21 Console. writeline ( " {0 }:{ 1} " , Pro. Name, O. tostring ());
22 Else
23 Console. writeline ( " {0 }:{ 1} " , Pro. Name, Null );
24
25 }
26

the performance of the above two methods is compared. Similarly, the results of repeated 100 times show that all attributes are retrieved using SP. The first test time is 187 ms, and the subsequent test is 171 Ms, the first time that some attributes (five attributes) are retrieved is 173 ms, and the test result is ms. the effect is not obvious. It may be that the Order object is not big data, and the attribute is not strong enough and cannot be fully reflected. in EDM, SP brings us more than that.
(the above are personal guesses)