When executed from Management Studio the stored procedure finishes in <0.1s, but when executed via EF it takes over 2s.
Below is profiler output:
A bit ironic since the reason for creating the SP was to improve performance on an EF query that took around 1.2s.
UPDATE For whatever it is worth, the SP result is mapped to an EF complex type. I call without any hocus pocus:
var menuTags = db.GetMenuTags(2, "en-US");
The SQL generated by EF is:
exec [dbo].[GetMenuTags] @CustTypeId=2,@LanguageId='en-US '
The only difference is a bunch of blank spaces EF adds to the end of @LanguageId, but they don't affect the performance. I have tried the exact same SQL in MSSMS and it works just as well as without the blank spaces.
SPs executed via EF always return all rows, could that be the delay.
Maybe posting your SP and the original EF generated SQL will help
Edited to add what appears to be the solution
Another thought (from days gone by) Parameter sniffing was oft the culprit for a slow SP which had been run by a developer with bad parameters and then set up a crappy execution plan. Adding the WITH RECOMPILE option to get a new plan based on decent parameters would resolve this problem mostly. Another cheat was to assign the passed in parameters into local sql variables (local to the SP) and only use local variables in the query.
Now you have the SP with a decent execution plan you should be able to remove the 'WITH RECOMPILE' and it'll still work. Parameter Sniffing problems are rare I would say.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With