|
it's just a mistake on typing. I have corrected in my question.
I try 2 queries with different condition , just to show that even the second query read more records , it's faster.
Of course , If I do the same query the first and the second time , the second time is faster.
|
|
|
|
|
How does one query return only 1 record, but the same query run later returns 400? Or is that another typo? It may be that information is cached in the server, so it is found faster the second time.
|
|
|
|
|
The first query has the condition >5 , the second query has the condition <5.
It's not the same query.
|
|
|
|
|
Then you are still making different comparisons so your test is not valid.
|
|
|
|
|
Sorry but if you can see the 2 query are very similar , and different only by the condition.
Anyway , the general problem is this :
The first query executed against an entity is too slow , the others are faster.
The same thing when executing query for the first time against other entities.
|
|
|
|
|
Richard MacCutchan wrote: The first includes a where clause, which means the database must read every record and test for that condition.
Not if you have a reasonable index on the table.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
How did you measure it being "too slow"? Did you find a "faster" way?
It may be faster the second time for a number of reasons, like having an open and authenticated connection, having the table in cache, SQL Servers' optimizer, SQL Servers' memory being paged from disc, etc. Yes, with 401 records, SQL Server will have to look at all the records - but should be fast indeed once they are in the cache - depending on the column-definition, it may hold the entire table there.
Of that first query, how long is it really executing the task on SQL Server, and how does that compare to the total waiting time?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
On top of what everyone else has said, Entity Framework itself has a "warm up time" with the very first query your app makes each time the app is launched. This is where Entity Framework is going through the entity classes and compares the structure against the database to make sure nothing changed. Obviously, this takes time.
If you really wanted to compare apples to apples, you have to get Entity Framework to make a different query first, one where you're going to throw the results away, just to get EF through its warm up time.
The only catch, EF6 has a pretty short warm up time, a few seconds for most models.
|
|
|
|
|
Ok , but how to force EF to do this "Warm Up Time" on another moment for example at program startup , because the user is better to wait some more time at program startup than when he need to do a specific job.
Yes , I can call a query , but what if the entities number is too high ?
|
|
|
|
|
I already told you how.
satc wrote: but what if the entities number is too high ?
It doesn't matter at all. You just have to execute a single query, ANY query against the database, even if it doesn't return any records. That is enough to get EF to do it's warm up work.
|
|
|
|
|
I think that's not true.
I wrote in my original question , that if I execute a query against a entity fro the first time , it need more time , second time it's faster.
But after if I try to execute another query against another entity for the first time , it's the same situation , this first query it's slower , and after the queries are faster.
And if at some point I do
context = new myentities
the situation is repeated like in the beginning.
|
|
|
|
|
I did not say that it was the cause of your problem.
All I said was Entity Framework has a warm up time to validate the database against the object model on the first query.
I have no idea what's causing your entire problem, other than probably bad indexing on the database. You have to setup any appropriate indexes on the database tables yourself. Entity Framework won't do it for you.
|
|
|
|
|
I've already done the indexing.
But anyway , I think a bad indexing would cause problems every time , not only the first time.
|
|
|
|
|
Dave Kreskowiak wrote: Entity Framework itself has a "warm up time" with the very first query
Just another nail in the EF coffin. What a POS.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Not like I had experience with a lot of different "heavy weight" ORMs but I can't imagine how it could be any different unless you/it deliberately skip(s) schema validation. And I don't think it's a big deal given it's a one time thing. There are probably other things more worth complaining about 
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Sascha Lefèvre wrote: There are probably other things more worth complaining about
Hence the comment "another nail". I loathe over engineered, black box tools, I use them where they are the only viable alternative (UI controls from telerik) but a DAL/ORM/Kitchen Sink I can do without.
I have a data access class that is an 18k DLL that does 98% of my LOB work.
I have a ORM tool that is not included in the app an writes 90% of my WCF, various UI classes, it will produce the xaml for Telerik grids and enums for master tables. And it does not need "warm up time" 
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Well, I'm using it in a web app that has about 115 entity classes (tables) all on one context. The warm up time of EF6 is about 2.5 seconds. I don't consider it bad.
It makes the bulk of my work easier but it does have some downsides. The SQL it generates isn't the most efficient when thing get complicated and the change tracker isn't the fastest thing in the world but it does the job for my site, does it reliably well and does it within performance specifications.
I'd use it again for another project, depending on requirements, but there are a couple things I'd do differently, such as breaking my monolithic context into smaller contexts. I'd get a bit quicker warm up time, but I'd also get one with each context.
|
|
|
|
|
I dislike the reliance such a comprehensive tool engenders in junior devs, they build apps based around such tool and never really understand their data and how it is stored and retrieved. I'm old school, especially around the database and how it is designed and works.
Just looked at one of our apps, 112 tables, each with 2 stored procs (old school  ) and about 50% with a view.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I don't understand very well what do you mean.
So as you are "old school" , give me a counsel : On your opinion , should I use Entity Framework or not ?
|
|
|
|
|
Personally I would never recommend an aspiring developer use EF, you do not get to know your data structure and transport layer, EF does all the work for you.
However there are a lot of well respected devs that DO use it, but then they already have a deep knowledge of what the tool is doing.
You need to decide if you are going to be a tool user or a true developer with a deep understanding of your work. Time is also a constraint.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
|
Mycroft Holmes wrote: I have a ORM tool that is not included in the app an writes 90% of my WCF, various UI classes, it will produce the xaml for Telerik grids and enums for master tables. And it does not need "warm up time"
May I ask you to elaborate on that? As I'm currently writing my own ORM that also should generate code other than entities that's rather interesting to me. Is it an actual ORM or "just" a codegen tool? Is it an in-house solution or publicly available? Especially the part "various UI classes" sounds interesting - what kind of UI classes?
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
No you are correct it is just a code generation tool (ClassBuilder), I have a bunch of conventions, first field in a table will be the primary key, every table has modified date, each table with a FK will have a view, table name prefixed with vw and a few more.
Projects have a defined structure, models , viewmodels, DAL etc all have defined folders so the code gen can easily find the find the target .cs files.
ClassBuilder generates the CRUD stored procedures, models, data access and interface code is places their files in #regions. Enums and grid xaml is created on demand. #regions are replaced in existing .cs files when there are changes to the table/views.
I pinched ClassBuilder and DBOps from another developer in the 90s, written in VB5 I think. They have been rewritten many times in quite a few languages but have retained the same basic structure. I even have a DBOps for Oracle somewhere.
I guess it generates about 60% of my code, hand coded stored procs and the UI are all manual. Snippets in VS do another 10% of the UI code.
Send me an email and I will happily share it, I thought DBOps was in one of my articles but I was wrong.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
sorry , what this has to do with the question's topic ?
|
|
|
|
|
My bad, seem to have hijacked your thread, sorry.
Never underestimate the power of human stupidity
RAH
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
