21

Używam EF6 rc1 ze strategią Code First, bez prekompilowanych widoków i problem jest następujący: Jeśli skompiluję i uruchomię aplikację exe, to 15 sekund, aby uruchomić pierwsze zapytanie (w porządku, ponieważ wciąż pracuję nad wstępnie wygenerowanymi widokami). Ale jeśli mogę użyć programu Visual Studio 2013 Preview do debugowania dokładnie tę samą aplikację to trwa prawie 2 minuty przed uruchomieniem pierwszego zapytania:EF6/Code First: Super slow podczas pierwszego zapytania, ale tylko w debugowaniu

Dim Context = New MyEntities() 
Dim Query = From I in Context.Itens '' <--- The debug takes 2 minutes in here 
Dim Item = Query.FirstOrDefault() 

Czy istnieje sposób, aby usunąć ten dodatkowy czas? Czy robię coś złego tutaj?

Ps .: Sam kontekst nie jest skomplikowany, a jedynie pełen ponad 200 tabel.

Edycja: Okazało się, że problem polega na tym, że podczas debugowania EF wydaje się generować Widoki ignorując te wcześniej wygenerowane. Używanie kodu źródłowego z EF odkryłem, że nieruchomości:

IQueryProvider IQueryable.Provider 
    { 
     get 
     { 
      return _provider ?? (_provider = new DbQueryProvider(
               GetInternalQueryWithCheck("IQueryable.Provider").InternalContext, 
               GetInternalQueryWithCheck("IQueryable.Provider").ObjectQueryProvider)); 
     } 
    } 

gdzie czas jest konsumowane. Ale to jest dziwne, ponieważ zajmuje tylko czas w debugowaniu. Czy coś mi umyka?

Edytuj: Znaleziono więcej informacji dotyczących pytania: Korzystanie z monitora procesu (przez Sysinternals) Dowiedziałem się, że istnieje proces "desenv.exe", który zużywa mnóstwo czasu. Aby dokładniej określić czas pochłaniania przez "Wyjście wątku". Powtarza stos wyjścia gwintu 36 razy. Nie wiem, czy te informacje są bardzo przydatne, ale zapisałem ".cvs" ze stosem, tutaj jest jego ciało: [...] (edytuj: usunięto ciało ".cvs", mogę je opublikować ponownie przez komentarze, jeśli ktoś naprawdę myśli, że będzie przydatny, ale był mylący i zbyt duży.)

Edytuj: Zainstalowany VS2013 Ultimate i Entity Framework 6 RTM. Zainstalował Entity Framework Power Tools Beta 4 i użył go do wygenerowania Widoku. Nic się nie zmieniło ... Jeśli uruchomię program exe, zajmie to 20 sekund, jeśli debugowanie "Start" zajmie 120 sekund.

Edytuj: Utworzono mały projekt symulujący błąd: http://sdrv.ms/16pH9Vm Po prostu uruchom projekt w środowisku i bezpośrednio przez .exe, kliknij przycisk i porównaj czas ładowania.

+0

Jest to powszechny problem, który boryka EF dłuższego czasu, pomyślałem, że zamierzają rozwiązać go w EF6 .. ale może nie .. Jedno EF6 zapewnia to możliwość rozbicia modelu na wiele modeli, co może być najlepszym wyborem. –

+0

http://entityframework.codeplex.com/wikipage?title=Multi-tenant%20Migrations –

+0

Łamanie w wielu kontekstach nic nie zmieniło.Wszystkie konteksty są zgodne z "regułą", więc ładowanie ich zajmuje prawie ten sam czas, chyba że załaduję na żądanie, ale muszę załadować je wszystkie, ponieważ między nimi jest wiele kluczy obcych. –

Odpowiedz

12

Jest to znany problem z wydajnością w Lazy (który EF używa), gdy dołączony jest debugger. W tej chwili pracujemy nad poprawką (obecne podejście, na które patrzymy, usuwa użycie Lazy). Mamy nadzieję, że wkrótce prześlemy tę poprawkę w wydaniu poprawki. Możesz śledzić postępy tego problemu na naszej witrynie CodePlex - http://entityframework.codeplex.com/workitem/1778.

Więcej szczegółów na temat nadchodzącego wydania 6.0.2 poprawkę, która będzie zawierać poprawki tutaj - http://blogs.msdn.com/b/adonet/archive/2013/10/31/ef6-performance-issues.aspx

+0

Dziękuję, ponieważ jest to znany błąd, który zaznaczę jako odpowiedź i śledzę pracę codeplex. –

+2

Ta poprawka nadal ma problemy z wydajnością. –

-1

ja nie wiem, czy znalezieniu rozwiązania. Ale w moim przypadku miałem podobny problem, który zmarnował mnie blisko tydzień po wypróbowaniu różnych sugestii. W końcu znalazłem rozwiązanie, zmieniając mój web.config w optimizeCompilations = "true", a wydajność poprawiła się dramatycznie z 15-30 sekund na około 2 sekundy.

Powiązane problemy