A watched website never boils - debugging is sooooooo sl. oo. ooo. w
-
Asp.Net website, running through a local instance of IIS. And yes, it's a WebForms thing, bite me. .Net 4.7.1
Load up any old page, takes 600ms. Cool.
Turn debugging on. Load up any old page. 30 seconds, all server-side.
There's nothing bottlenecking in the database. The only difference is the debugger is on and attached to w3wp.exe.
What's the why with it? Any ideas where to start? Is there some stupid Visual Studio 2012 setting that says "Always make debugging fucking slow"?
Any tools I can drop in to measure the performance on a function / method level?
-
@Lorne-Kates said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
Turn debugging on. Load up any old page. 30 seconds, all server-side.
Very strange indeed.
-
@Lorne-Kates said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
What's the why with it? Any ideas where to start? Is there some stupid Visual Studio 2012 setting that says "Always make debugging fucking slow"?
Make sure that you have "Just My Code" turned on, and "Enable .NET Framework source stepping" & "Suppress JIT optimization on module load" turned off. (Tools -> Options -> Debugging, at least in not-ancient Visual Studio versions.)
With those settings, your code will still show you all the locals, but any framework or other not-in-the-solution DLLs will still have some degree of optimization used.
Any tools I can drop in to measure the performance on a function / method level?
Telerik's profiler was nice for that, but it got discontinued. Newer versions of VS have some good built-in tools, but in 2012, if they even exist, you'd need to have the Ultimate edition.
JetBrains still offers dotTrace, and Red Gate their ANTS Performance Profiler, but I've never used either one.
-
@Lorne-Kates Do you have ReSharper installed and turned on? That exact scenario is what made me finally throw ReSharper in the garbage.
-
@Unperverted-Vixen said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
Make sure that you have "Just My Code" turned on, and "Enable .NET Framework source stepping" & "Suppress JIT optimization on module load" turned off. (Tools -> Options -> Debugging, at least in not-ancient Visual Studio versions.)
Trying that now.
@Unperverted-Vixen said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
Telerik's profiler was nice for that, but it got discontinued. Newer versions of VS have some good built-in tools, but in 2012, if they even exist, you'd need to have the Ultimate edition.
JetBrains still offers dotTrace, and Red Gate their ANTS Performance Profiler, but I've never used either one.Noted, thanks!
-
@blakeyrat said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
@Lorne-Kates Do you have ReSharper installed and turned on? That exact scenario is what made me finally throw ReSharper in the garbage.
Nope, I don't think ReSharper has ever been installed ever. Which, from everything I've heard about it, is a good thing.
-
@Lorne-Kates said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
any old page, takes 600ms
wat
if you have 600ms on the server side outside of debug, you already have problems
-
@Gribnit Not for a first-load.
-
@blakeyrat on the server side? I could see 600ms to loaded, client-side, for first load as pretty decent.
-
@Gribnit Well it depends on how you're doing it. If you use IIS Express, it'll pre-compile the ASP.Net before the page is hit by the user. In that case, it should run at normal speed. If you're deploying to production IIS, it'll (generally, of course you can set this) wait until a page is hit before compiling it in which case the compilation time is added to the first-load time.
Either way I'd say 600ms for a first-load is pretty good. Especially if you're using a mega-bloat library like MVC or Entity Framework.
-
@blakeyrat you poor bastards
-
@Gribnit Yeah look at the performance once it's compiled, compared to your-- whatever the fuck you're comparing it too. It'll smoke that whatever the fuck it is.
-
@blakeyrat said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
mega-bloat library like MVC or Entity Framework
EF seems pretty neat and easy to use IME. Is there a better alternative?
-
@stillwater Just writing ADO queries or stored procedures. Or using EF but having it just run stored procedures for you instead of doing its wankery.
-
@blakeyrat Sprocs are just a maintenance nightmare, and setting EF up to use them seems like it's missing the point.
@stillwater said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
EF seems pretty neat and easy to use IME. Is there a better alternative?
Are you maintaining your schema or relying on EF to do that for you?
If you're keeping up the database yourself: you can use Dapper to get better query performance without having to hand-write the deserialization like you would with pure ADO queries. (You still have to write SQL unlike with EF, but at least it's not crap SQL.)
If EF's doing all your schema updates then I think you're stuck with it.
-
@stillwater said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
@blakeyrat said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
mega-bloat library like MVC or Entity Framework
EF seems pretty neat and easy to use IME. Is there a better alternative?
EF is great until the abstraction leaks and you find yourself having to do all sorts of crap to make it work how you want. Or until some idiot fucks up multi threading and it starts trying to use the same dbcontext to do multiple updates concurrently
-
@Jaloopa Or you find out it doesn't support passing a user-defined table variable into a stored procedure, something fucking SQL Server has supported for like a DECADE now.
-
@Unperverted-Vixen said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
Are you maintaining your schema or relying on EF to do that for you?
I've never used EF in production, it's all stored procedures there. For my personal stuff, I use EF cos I do not want to design the tables and write SQL. I like EF cos it lets me get away with being lazy for minor stuff.
Also, I spent like a month learning about all the different types of Querying and Optimization techniques, about CTEs and yadda yadda yadda. What is the point of all that shit if everyone is gonna be using Entity Framework? I have a nagging feeling Entity Framework was a hobby project inside Microsoft that went too far. Everybody seems so committed and serious about it.
-
@stillwater said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
Everybody seems so committed and serious about it.
I'm not. The only reason I use it is that it's what I know, and converting an existing project away from it threatens to be... painful.
-
@stillwater said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
For my personal stuff, I use EF cos I do not want to design the tables and write SQL. I like EF cos it lets me get away with being lazy for minor stuff.
That's probably okay. You're not getting the greatest performance, but for a personal project it's probably good enough.
Also, I spent like a month learning about all the different types of Querying and Optimization techniques, about CTEs and yadda yadda yadda. What is the point of all that shit if everyone is gonna be using Entity Framework?
Not everybody's going to be using Entity Framework, though. The DLLs are fat; well-done queries still tend to be slower than ADO.NET or Dapper*; and it's really easy to shoot yourself in the foot and generate not-so-well-done queries that hose performance without realizing it.
It does have some neat features. And I am using it in one of my professional projects. But I don't think I'd choose to use it again for a non-personal project.
- Supposedly EF Core 2.0 improves in this area.
-
@Unperverted-Vixen said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
Supposedly EF Core 2.0 improves in this area.
Yeah anything that's "CORE" apparently has improvements but the documentation of anything core is completely Cloud-Atlas-ed.
-
@stillwater said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
@Unperverted-Vixen said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
Supposedly EF Core 2.0 improves in this area.
Yeah anything that's "CORE" apparently has improvements but the documentation of anything core is completely Cloud-Atlas-ed.
How do you mean?
-
@kt_ The Docs are always catching up with the changes in the product and the product usually moves fast and this ends up invalidating some of the existing documentation. This results in documentation on the docs section and some more documentation in the GitHub issues / feedback section. So even if EF Core can cure cancer, we LL have to wait till the docs and the features are finalized and stable. Same with ASP .NET Core. Oh this is much much better now but the state of docs a few months back was absolute madness.
-
@Unperverted-Vixen said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
and it's really easy to shoot yourself in the foot and generate not-so-well-done queries that hose performance without realizing it.
It's also really easy to create run-time errors when using EF's LINQ-To-SQL, because there's a lot of stuff that's perfectly valid in LINQ but LINQ-To-SQL can't handle, and of course those aren't compiler errors because why would a C# library catch all errors at compilation-time.
This is also how I knew a useless co-worker of mine never actually wrote some code he claimed to have tested and checked-in to Master. I'm like "it's not like some obscure bug, the LINQ statement you wrote LITERALLY NEVER WORKED AND NEVER COULD HAVE WORKED."
If you just stick with EF's ability to run Stored Procedures with well-defined POCOs, most of its problems disappear.
-
@Jaloopa said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
EF is great until the abstraction leaks and
That's the point where you should use regular sqlcommands. There is no reason to use it where it isn't great. (wherever you draw the line of it stop being great)
-
@blakeyrat said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
If you just stick with EF's ability to run Stored Procedures with well-defined POCOs, most of its problems disappear.
+1 this.
I find myself doing that a lot more since many times the equivalent Linq is several times more obtuse than the desired SQL it's supposed to generate.
-
@Tsaukpaetra said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
+1 this.
... unless you need to pass-in a user-defined table variable to a stored procedure, which EF inexplicably doesn't support.
-
Oh for... This didn't used to be a problem, now I'm connecting to Azure for debugging and lo, I am experiencing the slow.
Yay....
-
@Lorne-Kates said in A watched website never boils - debugging is sooooooo sl. oo. ooo. w:
Load up any old page, takes 600ms. Cool.
Turn debugging on. Load up any old page. 30 seconds, all server-side.
There's nothing bottlenecking in the database. The only difference is the debugger is on and attached to w3wp.exe.
What's the why with it? Any ideas where to start? Is there some stupid Visual Studio 2012 setting that says "Always make debugging fucking slow"?If I had to guess, I'd say you're doing something at startup that throws and then handles a lot of exceptions. This is very fast... unless you're running under the debugger, and for each one it has to trap the exception, suspend your program, context-switch out of your program and to the IDE, examine the exception, see if it's handled, see if it's a type VS should break on or not, decide it's not, and then context-switch back to your program and resume execution.
Do that a thousand times or so and you get exactly the symptoms you're describing here.
To test for this, go into VS's Exception settings (
CTRL-ALT-E) and have it unconditionally break on all CLR exceptions, and then see if anything shows up a zillion times.
