Точка 1 я споменах, защото съм виждал такова измерване от  лекция.

Performance и  памет са различни и често противоречащи си неща, например кеширането. Идеята на Include e точно performance в определени заявки, защото е ясно, че паметта и мрежовият трафик са доста.  До каква степен и дали да се използва Include можем да прочетем тук

Направих обаче замервания на паметта за случите с ToList.

По точка 12, паметта при използване на Where.Select.ToList беше почти една и съща(около 7.2 MB) независимо от условието в where(тоест кои шоколади искам да си купя). Разликата в паметта при нула върнати и 1000 върнати резултати е горе долу същата,+/-5% Това показва, че изпълнението на самата заявка е много по скъпо като памет от данните, които връща. Използването на ToList.Where.Select даде около 3.3 МБ. Само ToList() дава същият резултат. Само Where е 5.1 MB, Select също 5.1 МБ. Очевидно в тези случаи, че ToList() в началото е повече от 2 пъти по-бърза от ToList() в края. ToList() e по-евтина от Where и Select(). Това е при стратегия MigrateDatabaseToLatestVersion.

При DropCreateDatabaseIfModelChanges стратегия само ToList() e 5.5 MB, Select 3.3 MB, Where също 3.3 МБ. Слагането на ToList() преди или след Where() и Select() няма никакво почти никакво значение, има 50 KB повече ако е в началото.

Тези измервания са правени с GC, не с memory profiler.

Та от разгледаните случаи изглежда, че ToList() дърпа повече памет в някои стратегии, докато в други намалява паметта, а разликата в скоростта с него не е много голяма. За съжаление тука никакви метафори не вървят, вземат се предвид много повече неща от това, дали първо да избираме шоколадите и след това да ни ги дават. Може понякога клиента да е по-оправен от продавача и алгоритъмът му на събиране от купчината да е по-добър. Освен всичко друго, може и продавачът да е зает, да му е по-лесно да ти даде цялата купчина и да ти каже "аз съм зает, ако искаш оправяй се, нали можеш и сам".

Имах предвид, че ако съм потребител и искам да видя една картинка от базата, моята машина няма нужда да тегли всички картинки, че да ми селектне тази, която аз искам да видя(смисъла на примера със шоколадите). Ако направиш ToList() преди да си избрал конкретно това, което искаш да видиш, ще събереш сташно много информация, която не ти трябва.

И аз си мислех така преди. Въпросът е дали sql прави по-бързо това, което прави само linq. От това, което мерих, излиза, че паметта използвана с ToList() първо при някои стратегии е по-малко, а скоростта е кажи-речи същата. Излиза, че linq на локално ниво се справя доста добре, дори и цената в памет да се използва локално може да е примамлива. А иначе, споменатият от тебе конкретен пример звучи като случай 3, където се използва ToList().FirstOrDefault(), което наистина е безсмислено, но го направих доколкото си спомням, за да видя дали има някакви оптимизации. Е явно няма, а такава заявка надали някой ще направи и без това.

За кое от всичките неща говориш, Lazy vs Eager, Native скоростта или N + 1  проблема? Lazy vs Eager се моделира спрямо ситуацията, Native е за предпочитане при Delete и извикване на сторнати процедури , за Bulk заявките си има Extended библиотеката. За N + 1 може би е така, ако приемем, че sql сървърите се натоварват повече, макар да използват оптимизации.

Има и един момент, че зависи колко на брой подобни заявки се изпълняват една след друга. Например 1 заявка Include е в пъти по-бавна от 1 lazy, при 1000 и при 10000 те са почти същите като време. Като правих измерванията използвах минимално 100 итерации заради усредненото време, ама това се оказва, че също може да влияе на резултатите. Причинaта, доколкото разбирам е в модела на използване на т. н. execution plans и свързаното plan cache(не зареждането на поръчките при eager loading в ObjectStateManager-a).

Това, което трябва да се прави когато се препоръчва определен модел на заявките е не да се търси универсално решение, защото такова няма, а да се аргументира при кои условия кое решение най-добро. Затова и "не използвайте ToList()" само по себе си не върви.