4 ms·

ASP.NET wasn't necessarily slow previously - for example, StackOverflow is running on it, and they're getting some pretty good perf (albeit with pretty beefy ma

ASP.NET wasn't necessarily slow previously - for example, StackOverflow is running on it, and they're getting some pretty good perf (albeit with pretty beefy machines): http://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ http://nickcraver.com/blog/2016/02/17/stack-overflow-the-arc... Most sites, even relatively high traffic sites, don't serve 50k requests per second. However, it wasn't granular or modular. For a lot of sites, it was a good balance of features to performance, but in a lot of cases you paid a performance penalty for features you weren't using. That includes the memory footprint penalty - each ASP.NET site loaded up a chunky system.web DLL with the kitchen sink. Back in the day that was fine, but as there are a lot of front-end heavy sites now that use servers mostly as API endpoints, and package managers are pretty standard, devs like to only pay the performance cost (including memory footprint) for the features, middleware, etc., that they're using. That was a big design consideration for ASP.NET Core, and you can really see the results in these specific benchmarks (Techempower plaintext).

kristianp 11y ago
Speaking of performance. I read that blog entry, and saw that they use their own DB library called Dapper: https://github.com/StackExchange/dapper-dot-net https://github.com/StackExchange/dapper-dot-net I was suprised to see that it's almost 4x faster than linq2sql and more than 10x faster than entity framework. (according to the table "Performance of SELECT mapping over 500 iterations - POCO serialization"). There must be a lot of slow sites out there running on entity.
- jongalloway2 11y ago
  They're different kinds of tools - maybe like comparing an RV to a motorcycle, or a guided missile to a sniper rifle. Or a... Well, anyhow, while at a high level they're both tools that map between database commands and statically typed objects, the approach is very different. Entity Framework is a full object relational mapper - it's generally the active record pattern, and it supplies things like migrations and entity tracking. The design philosophy is to abstract the database mechanics as much as possible, so you just work with collections of objects (e.g. DbSet<Person>) - add new Person instances to the set, set properties on them, etc. EF converts your intent into database commands (SQL queries in many cases, although EF7 supports some non-relational databases and in-memory storage, too). EF is tracking the state of all your objects, so it knows whether they need to be updated in the data store. That might be fine for a lot of cases - if you're managing a small list of products or customers, working on an intranet app, etc., you're not going to see a difference. I've seen (and fixed) a lot of horrible SQL queries that intranet devs built by concatenating strings; EF is at least going to usually give you decent, secure SQL. (If you're gnashing your teeth right now because EF crushed your dreams in the past, they've done some decent work on SQL generation lately, including some good stuff in EF7). It works pretty well on a lot of apps in lots of dev shops, and can be tuned to work well on big apps if you know what you're doing. Dapper, and other "micro-ORMs" want to work closer to the metal. Dapper's tuned to taking the results of a database command (SQL query) and populate static objects. There's no entity tracking, state management, etc. Take results of a database query, stuff it into a bunch of object properties, walk away. Because of that, benchmarks showing the performance of select mapping over 500 iterations - POCO serialization are going to run a lot faster, just as (sorry, can't help myself) a motorcycle's going to beat an RV on a race down a tiny dirt trail. So there may be some slow sites that are running on EF that would be faster on Dapper, but not without evaluating how they're interacting with the database, how they're doing database updates, etc. Also, to be fair, you can disable a lot of features in EF (or other more fully featured ORMs) and get perf numbers pretty close to micro-ORM's like Dapper. See this comparison: https://github.com/StackExchange/dapper-dot-net/issues/246#issuecomment-90598911 https://github.com/StackExchange/dapper-dot-net/issues/246#i... However, if you're turning off all the features and hand crafting SQL statements and working with untracked entities, you probably want a micro-ORM, anyways.
  - yread 11y ago
    Great explanation. If you want to get even closer to the metal there is Simple.Data http://simplefx.org/simpledata/docs/ http://simplefx.org/simpledata/docs/ where you write queries like var albums = Database.Open().Albums.FindAll(db.Albums.GenreId == 1); //or FindAllByGenreId(1) foreach (var album in albums) { Console.WriteLine(album.Title); } and they return dynamic objects. It's smart about cases, _s and all with 0 configuration.

kristianp 11y ago

Speaking of performance. I read that blog entry, and saw that they use their own DB library called Dapper: https://github.com/StackExchange/dapper-dot-net https://github.com/StackExchange/dapper-dot-net I was suprised to see that it's almost 4x faster than linq2sql and more than 10x faster than entity framework. (according to the table "Performance of SELECT mapping over 500 iterations - POCO serialization"). There must be a lot of slow sites out there running on entity.

jongalloway2 11y ago
They're different kinds of tools - maybe like comparing an RV to a motorcycle, or a guided missile to a sniper rifle. Or a... Well, anyhow, while at a high level they're both tools that map between database commands and statically typed objects, the approach is very different. Entity Framework is a full object relational mapper - it's generally the active record pattern, and it supplies things like migrations and entity tracking. The design philosophy is to abstract the database mechanics as much as possible, so you just work with collections of objects (e.g. DbSet<Person>) - add new Person instances to the set, set properties on them, etc. EF converts your intent into database commands (SQL queries in many cases, although EF7 supports some non-relational databases and in-memory storage, too). EF is tracking the state of all your objects, so it knows whether they need to be updated in the data store. That might be fine for a lot of cases - if you're managing a small list of products or customers, working on an intranet app, etc., you're not going to see a difference. I've seen (and fixed) a lot of horrible SQL queries that intranet devs built by concatenating strings; EF is at least going to usually give you decent, secure SQL. (If you're gnashing your teeth right now because EF crushed your dreams in the past, they've done some decent work on SQL generation lately, including some good stuff in EF7). It works pretty well on a lot of apps in lots of dev shops, and can be tuned to work well on big apps if you know what you're doing. Dapper, and other "micro-ORMs" want to work closer to the metal. Dapper's tuned to taking the results of a database command (SQL query) and populate static objects. There's no entity tracking, state management, etc. Take results of a database query, stuff it into a bunch of object properties, walk away. Because of that, benchmarks showing the performance of select mapping over 500 iterations - POCO serialization are going to run a lot faster, just as (sorry, can't help myself) a motorcycle's going to beat an RV on a race down a tiny dirt trail. So there may be some slow sites that are running on EF that would be faster on Dapper, but not without evaluating how they're interacting with the database, how they're doing database updates, etc. Also, to be fair, you can disable a lot of features in EF (or other more fully featured ORMs) and get perf numbers pretty close to micro-ORM's like Dapper. See this comparison: https://github.com/StackExchange/dapper-dot-net/issues/246#issuecomment-90598911 https://github.com/StackExchange/dapper-dot-net/issues/246#i... However, if you're turning off all the features and hand crafting SQL statements and working with untracked entities, you probably want a micro-ORM, anyways.
- yread 11y ago
  Great explanation. If you want to get even closer to the metal there is Simple.Data http://simplefx.org/simpledata/docs/ http://simplefx.org/simpledata/docs/ where you write queries like var albums = Database.Open().Albums.FindAll(db.Albums.GenreId == 1); //or FindAllByGenreId(1) foreach (var album in albums) { Console.WriteLine(album.Title); } and they return dynamic objects. It's smart about cases, _s and all with 0 configuration.