Utterly strange performance in the Entity Framework

Hello!

I'm trying the new Entity framework and I must say that I observe an utterly strange performance result. Is there a way to submit my solution for investigation at Microsoft?

Best regards,

Henrik Dahl

Hi Henrik,

Please briefly describe your scenario and the expected result and send me the solution for investigation to nvalluri at microsoft dot com.

regards,

Naveen Valluri,

I've now submitted the stuff to you.

Do you think you have a chance to look at it in short time - I'm really looking forward hearing from you?

Best regards,

Henrik Dahl

Naveen Valluri,

Have you managed to observe the same amazing consumption of computational resources when running the solution?

Best regards,

Henrik Dahl

Sorry for the delay in response. Naveen is actually out sick today. We'll try to connect with him and get back to you as soon as we can. Given that I don't have the details of your situation, I can't speak to it, but I will say that one of the things we are working on during this development milestone is a significant push for performance improvements... The difference in beta 3 should be really noticeable for some scenarios.

- Danny

Hello Danny!

OK.

I imagine Naveen will be sick for only a few days. I may easily wait for that and let him to recover in peace!

It sounds good with significant performance improvements. In the current case it took multiple hours to insert a singular row in a singular table so I think that here there's really room for multiple orders of magnitude of performance improvements.

Despite it's not really the subject of this thread, do you know of a rough estimation of availability of beta 3, is it for instance assumed to be released during the year of 2007?

Best regards,

Henrik Dahl

The intention is to line up beta 3 of the EF with Orcas RTM. So, yes, we intend that it will ship sometime before the end of this calendar year, but of course there are lots of things that could change between now and then.

- Danny

Daniel,

Yes, it's obvious, but thank you for sharing this.

I look forward hearing from Naveen as he'll be back again.

Best regards,

Henrik Dahl

Hi Henrik,

Thanks for your patience. We did observe the delay in inserting the record for the first time and this is in part because the framework compiles the model files. Any queries, inserts or updates after that is in sub-second range. In the current milestone, we have been working on improving the performance in this area. We tried your scenarios against our latest bits, which you will see delivered as part of Beta 3 in late November and the performance has significantly improved. The time to compile the model files is reduced to 20 seconds. Again, to reiterate, this is only the first time that CRUD operation goes to the server . Even for this, we are working towards making this happen during design time, so that the cost isn’t there at runtime.

Thanks,

Naveen

Given that view compilation is the source of the problem, you can also pre-compile your views even in beta 2, and then you will have a big hit during this initial step, but at runtime that hit will go away. I've been meaning to write a blog post on how to do that, but haven't gotten to it yet. Suddenly I feel motivated--now if only I could get the time to do it... The clue I'll give you now is to look at the commandline options on edmgen where there's a generateviews or something like that. This will output code that is a compiled version of the views which the EF uses for queries and updates. You can compile that into your assembly, and then things should get much faster at runtime.

- Danny

Utterly strange performance in the Entity Framework

Hello!

I'm trying the new Entity framework and I must say that I observe an utterly strange performance result. Is there a way to submit my solution for investigation at Microsoft?

Best regards,

Henrik Dahl

Hi Henrik,

Please briefly describe your scenario and the expected result and send me the solution for investigation to nvalluri at microsoft dot com.

regards,

Naveen Valluri,

I've now submitted the stuff to you.

Do you think you have a chance to look at it in short time - I'm really looking forward hearing from you?

Best regards,

Henrik Dahl

Naveen Valluri,

Have you managed to observe the same amazing consumption of computational resources when running the solution?

Best regards,

Henrik Dahl

Sorry for the delay in response. Naveen is actually out sick today. We'll try to connect with him and get back to you as soon as we can. Given that I don't have the details of your situation, I can't speak to it, but I will say that one of the things we are working on during this development milestone is a significant push for performance improvements... The difference in beta 3 should be really noticeable for some scenarios.

- Danny

Hello Danny!

OK.

I imagine Naveen will be sick for only a few days. I may easily wait for that and let him to recover in peace!

It sounds good with significant performance improvements. In the current case it took multiple hours to insert a singular row in a singular table so I think that here there's really room for multiple orders of magnitude of performance improvements.

Despite it's not really the subject of this thread, do you know of a rough estimation of availability of beta 3, is it for instance assumed to be released during the year of 2007?

Best regards,

Henrik Dahl

The intention is to line up beta 3 of the EF with Orcas RTM. So, yes, we intend that it will ship sometime before the end of this calendar year, but of course there are lots of things that could change between now and then.

- Danny

Daniel,

Yes, it's obvious, but thank you for sharing this.

I look forward hearing from Naveen as he'll be back again.

Best regards,

Henrik Dahl

Hi Henrik,

Thanks for your patience. We did observe the delay in inserting the record for the first time and this is in part because the framework compiles the model files. Any queries, inserts or updates after that is in sub-second range. In the current milestone, we have been working on improving the performance in this area. We tried your scenarios against our latest bits, which you will see delivered as part of Beta 3 in late November and the performance has significantly improved. The time to compile the model files is reduced to 20 seconds. Again, to reiterate, this is only the first time that CRUD operation goes to the server . Even for this, we are working towards making this happen during design time, so that the cost isn’t there at runtime.

Thanks,

Naveen

Given that view compilation is the source of the problem, you can also pre-compile your views even in beta 2, and then you will have a big hit during this initial step, but at runtime that hit will go away. I've been meaning to write a blog post on how to do that, but haven't gotten to it yet. Suddenly I feel motivated--now if only I could get the time to do it... The clue I'll give you now is to look at the commandline options on edmgen where there's a generateviews or something like that. This will output code that is a compiled version of the views which the EF uses for queries and updates. You can compile that into your assembly, and then things should get much faster at runtime.

- Danny

Utterly strange performance in the Entity Framework

Hello!

I'm trying the new Entity framework and I must say that I observe an utterly strange performance result. Is there a way to submit my solution for investigation at Microsoft?

Best regards,

Henrik Dahl

Hi Henrik,

Please briefly describe your scenario and the expected result and send me the solution for investigation to nvalluri at microsoft dot com.

regards,

Naveen Valluri,

I've now submitted the stuff to you.

Do you think you have a chance to look at it in short time - I'm really looking forward hearing from you?

Best regards,

Henrik Dahl

Naveen Valluri,

Have you managed to observe the same amazing consumption of computational resources when running the solution?

Best regards,

Henrik Dahl

Sorry for the delay in response. Naveen is actually out sick today. We'll try to connect with him and get back to you as soon as we can. Given that I don't have the details of your situation, I can't speak to it, but I will say that one of the things we are working on during this development milestone is a significant push for performance improvements... The difference in beta 3 should be really noticeable for some scenarios.

- Danny

Hello Danny!

OK.

I imagine Naveen will be sick for only a few days. I may easily wait for that and let him to recover in peace!

It sounds good with significant performance improvements. In the current case it took multiple hours to insert a singular row in a singular table so I think that here there's really room for multiple orders of magnitude of performance improvements.

Despite it's not really the subject of this thread, do you know of a rough estimation of availability of beta 3, is it for instance assumed to be released during the year of 2007?

Best regards,

Henrik Dahl

The intention is to line up beta 3 of the EF with Orcas RTM. So, yes, we intend that it will ship sometime before the end of this calendar year, but of course there are lots of things that could change between now and then.

- Danny

Daniel,

Yes, it's obvious, but thank you for sharing this.

I look forward hearing from Naveen as he'll be back again.

Best regards,

Henrik Dahl

Hi Henrik,

Thanks for your patience. We did observe the delay in inserting the record for the first time and this is in part because the framework compiles the model files. Any queries, inserts or updates after that is in sub-second range. In the current milestone, we have been working on improving the performance in this area. We tried your scenarios against our latest bits, which you will see delivered as part of Beta 3 in late November and the performance has significantly improved. The time to compile the model files is reduced to 20 seconds. Again, to reiterate, this is only the first time that CRUD operation goes to the server . Even for this, we are working towards making this happen during design time, so that the cost isn’t there at runtime.

Thanks,

Naveen

Given that view compilation is the source of the problem, you can also pre-compile your views even in beta 2, and then you will have a big hit during this initial step, but at runtime that hit will go away. I've been meaning to write a blog post on how to do that, but haven't gotten to it yet. Suddenly I feel motivated--now if only I could get the time to do it... The clue I'll give you now is to look at the commandline options on edmgen where there's a generateviews or something like that. This will output code that is a compiled version of the views which the EF uses for queries and updates. You can compile that into your assembly, and then things should get much faster at runtime.

- Danny

V$session : Session not Closed

I connect to Oracle DB thru JDBC. I used CLIENT_INFO field in V$SESSION to store my intranet Application's User Name along with Username.
I controlled the user access thru checking that field. I assumed even if user goes out of that page, session will be closed automatically. But one of client went to other page by mistaken. He restarted the IE as well his own machine. But still the session is not closed. I can see the session in V$session.
Any idea whether such problems are preventable. i cannot even close that session from my machine. How to close that session.
Thank you in advance..Note that you probably want to address JDBC questions to the JDBC forum rather than the ODBC forum-- different protocols, different products.
Justin

v1.1 - datagrid - naming headers

hi,

I have had to create a bunch of field names in my table as (i.e) "20071225" (for 25-dec-2007).

But in my datagrid I want "25-dec-2007" as my column headers.

How would i achieve this?

Thanks,

John

I've answered my own question in case anyone else was interested.

I wanted to change my "col" (foreach(DataColumn colin dt.Columns) )

- where col.ColumnName.ToString() = "20071225"

I ended up changing the DataTable column names and then the bind to the Datagrid simply picked them up correctly.

-------

string stopval = col.ColumnName.ToString();

string year = stopval.Substring(0, 4);

string month = stopval.Substring(4, 2);

string day = stopval.Substring(6, 2);

// extra faffing to get MON

dtme = Convert.ToDateTime(day + "-" + month + "-" + year);

string strMonth = dtme.ToString("MMM");

col.ColumnName = day + "-" + strMonth + "-" + year;

--------

- now col.ColumnName.ToString() = "25-Dec-2007"

V8.16 returns error message upon opening database.

When opening a database using V8.16 support files and drivers the following error message is returned. "ODBC - Tunnel Error ORA-01456: may not perform insert/delete/update operation inside a READ ONLY transaction.
This error does not occur using V8.15.
What is the cause of this problem?You don't by any chance have the 'connect in read-only mode' option checked on your DSN do you?
Justin Cave

Vague error on data source - hard to debug

I have this error:

Server Error in '/247 Website' Application.

---

A field or property with the name 'armAreaName' was not found on the selected data source.

I have several data sources, any ideas if I can find outwhichdata source is at error here?

Look at your code. It will be the one that tries to reference a field called armAreaName.

Ok fair enough, I found it in my code eventually. I find its difficult to find the error working in design mode so I switched to code mode. However it would be nice if the error specified at least the datasource which was falling over.

Thanks anyway.

Design Mode has very few practical uses. Drag and drop and double click for event handlers is about it. It's definitely not the place to be when trying to debug runtime errors.