codesmithtools / Templates

CodeSmith Generator Templates
http://www.codesmithtools.com/product/generator
54 stars 35 forks source link

PLINQO EF: Generation is much slower than for Linq to SQL #570

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
For our large project we are getting very slow generation when include 
functions and views is true.

Original issue reported on code.google.com by kachalkov on 6 Apr 2011 at 12:56

GoogleCodeExporter commented 9 years ago
About how much longer is it taking compared to PLINQO? It is using a totally 
new engine under the hood than PLINQO is currently using.

Original comment by bniemyjski on 8 Apr 2011 at 12:08

GoogleCodeExporter commented 9 years ago
We already submitted issue about slow parsing of large stored procedures to 
codesmith support...
The problem was in stored procedure with 3000 lines of code, but we have a 
hotfix version of codesmith v5.3.

With vs 2010 and T4 templates we are thinking what is the advantage of using 
codesmith templates?

Original comment by kachalkov on 8 Apr 2011 at 12:38

GoogleCodeExporter commented 9 years ago
Hello,

Do you have a case number that I can reference. I'll be doing profiling on the 
templates today! We will be doing a new blog post specifically stating the 
differences, but they are outlined here what are the differences between T4 and 
CodeSmith Generator 
(http://community.codesmithtools.com/CodeSmith_Official_7/b/announcements/archiv
e/2011/03/30/PLINQO-for-Entity-Framework-Templates-Beta-1-Released.aspx).

We will be adding additional items to that list like better Many-to-Many 
detection logic than what Microsoft Provides.

Original comment by bniemyjski on 8 Apr 2011 at 5:31

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
it's seem a bit quicker after we applied our current ignore list...

Original comment by kachalkov on 11 Apr 2011 at 7:59

GoogleCodeExporter commented 9 years ago
actually this is after excluding stored procedures and views...

Original comment by kachalkov on 11 Apr 2011 at 8:02

GoogleCodeExporter commented 9 years ago
(Case 03254503) CodeSmith Generator v5.3 Large Database hang issue

Original comment by kachalkov on 11 Apr 2011 at 8:03

GoogleCodeExporter commented 9 years ago
built in edmx designer works much quicker...

Original comment by kachalkov on 12 Apr 2011 at 1:39

GoogleCodeExporter commented 9 years ago
Thanks for your feedback, I'll be taking a very close into this.

Original comment by bniemyjski on 12 Apr 2011 at 6:23

GoogleCodeExporter commented 9 years ago
Hello,

I went ahead and profiled the the latest nightly build and made some changes 
((http://community.codesmithtools.com/nightly/PLINQOEF/)). It should be much 
faster in the latest build that was just committed. 

Also for the bug that causes this Stored Procedure has to do with Regex Back 
Tracking and its almost impossible to track down why the Regex is behaving this 
way. Every Regex debugging tool fails miserably in this regard. If you by 
chance are a Regex god or know of one you would like to take a shot at 
debugging this open sourced Regex... I'd be more than willing to set up a 
meeting and show you how to debug the Regex in question against your stored 
procedure. 

It has been logged in our internal bug tracker as high priority and the changes 
that we made in 5.3.4 made it slightly faster... However, we will take another 
pass at solving in a future version of CodeSmith Generator (We currently have 
spent about 3 days and two developers to resolve this root issue) trying to 
track down and then fix this Regex. Some context of the scope of this bug... 
Since the SQLSchemaProvider was written in ~2002, this is the only stored 
procedure ever to cause this behavior :\.

Please let us know if you have any questions.

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 14 Apr 2011 at 1:44

GoogleCodeExporter commented 9 years ago
I understand that issue with hanging was unique to that 3000 lines stored 
procedure we got and it's not an issue for us as we can exclude it as a 
workaround.

Generally comparing speed of generation for the built in designer against our 
database  with functions and stored procedures and views makes a difference...

I will try latest nightly build anyway and will let you know.

Original comment by kachalkov on 15 Apr 2011 at 12:04

GoogleCodeExporter commented 9 years ago
Hello,

Thanks for the heads up, Please let us know how it works in the nightly build.

Thanks
-Blake

Original comment by bniemyjski on 15 Apr 2011 at 3:52

GoogleCodeExporter commented 9 years ago

Original comment by bniemyjski on 15 Jun 2011 at 11:27