Databases
StackOverflow2013
Postsdbo
PO7-second EF startup time even for tiny DbContext
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO7-second EF startup time even for tiny DbContext
    primarykey
    data
    text
    <p>I am trying to reduce the startup time of my EF-based application, but I find that I cannot reduce the amount of time taken for an initial read below 7 seconds even for a single-entity context. What's especially strange is that this time is not context-type specific. </p> <p>Can anyone explain what causes these slow times and/or how I can get things to run faster?</p> <p>Here's the complete sample code:</p> <p>In my database, I have a table named se_stores with a primary key column AptId:</p> <pre><code> // a sample entity class public class Apartment { public int AptId { get; set; } } // two identical DbContexts public class MyDbContext1 : DbContext { public MyDbContext1(string connectionString) : base(connectionString) { } protected override void OnModelCreating(DbModelBuilder modelBuilder) { Database.SetInitializer&lt;MyDbContext1&gt;(null); var config = new EntityTypeConfiguration&lt;Apartment&gt;(); config.HasKey(a =&gt; a.AptId).ToTable("se_stores"); modelBuilder.Configurations.Add(config); base.OnModelCreating(modelBuilder); } } public class MyDbContext2 : DbContext { public MyDbContext2(string connectionString) : base(connectionString) { } protected override void OnModelCreating(DbModelBuilder modelBuilder) { Database.SetInitializer&lt;MyDbContext2&gt;(null); var config = new EntityTypeConfiguration&lt;Apartment&gt;(); config.HasKey(a =&gt; a.AptId).ToTable("apartments"); modelBuilder.Configurations.Add(config); base.OnModelCreating(modelBuilder); } } // finally, I run this code using NUnit: var start = DateTime.Now; var apt1 = new MyDbContext1(connectionString).Set&lt;Apartment&gt;().FirstOrDefault(); var t1 = DateTime.Now - start; start = DateTime.Now; var apt2 = new MyDbContext2(connectionString).Set&lt;Apartment&gt;().FirstOrDefault(); var t2 = DateTime.Now - start; Console.WriteLine(t1.TotalSeconds + ", " + t2.TotalSeconds); </code></pre> <p>It reliably prints something like the following: 7.5277527, 0.060006. When I switch the test to use MyDbContext2 first, I get the same result (so it happens for whichever DbContext gets initialized first). I also tried pre-generating views using EF power tools. This reduced the time for the first context to around 6.8 seconds, and thus was only a small win.</p> <p>I understand that DateTime.Now is a terrible profiling method, but these results have held up while using dotTrace. I'm also aware that running some code for the first time invokes a JITing cost, but 7 seconds seems far too high to attribute to that. </p> <p>I am using EF 4.3.1 and .NET 4 with VS 2010.</p> <p>Thanks in advance for your help!</p> <p>EDIT: It was suggested that opening the SQL connection might be causing the problem. </p> <ol> <li>I first tried running a random query using a raw SqlConnection and create command with the same connection string. This took 1 second and did not affect the time of DbContext initialization.</li> <li>I then tried creating a SqlConnection with the connection string and passing it through to DbContext's constructor that takes a connection. I passed contextOwnsConnection=false. This also made no difference in the DbContext initialization time.</li> <li>Finally, I tried connecting through management studio using the same credentials and connection string options. This was nearly instantaneous.</li> <li>In the dotTrace profile, it measures SqlConnectionFactory.CreateConnection(connectionString) as taking 0.7 seconds, which is consistent with the raw SQL time.</li> </ol> <p>EDIT: I wanted to know if the delay was per connection or once only. Thus, I tried having MyDbContext1 and MyDbContext2 connect to entirely different databases on different servers. This DID NOT make a difference regardless of which database was connected to first: the use of a first DbContext took ~7 seconds, while the use of a second context is blazingly fast.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USChaseMedallion
    1. USChaseMedallion
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. PO7-second EF startup time even for tiny DbContext
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO7-second EF startup time even for tiny DbContext
      1. USChaseMedallion
      1. VTFavorite
    3. VO
      singulars
      1. PO7-second EF startup time even for tiny DbContext
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO[Performance Considerations (Entity Framework)](http://msdn.microsoft.com/en-us/library/cc853327.aspx)
      singulars
      1. PO7-second EF startup time even for tiny DbContext
      1. USjrummell
    2. CO@jrummell: That is a good link (I've read it before). Was there a particular section that you thought addressed my issue?
      singulars
      1. PO7-second EF startup time even for tiny DbContext
      1. USChaseMedallion
    3. COFirst, you should be using the StopWatch class to do timings. It's far more accurate. Second, pre-generating views may help some (but on such a small context, i can't see how it would help much). You can use the EF Power Tools to auto-generate views from a DbContext.
      singulars
      1. PO7-second EF startup time even for tiny DbContext
      1. USErik Funkenbusch
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload