4 ms·

We saw about a 45% improvement in our API. EF Core also appears to have improved performance.

by skrowl 6y ago

y-c-o-m-b 6y ago
Still slower than Dapper though? I like Dapper and we use it where I currently work, but it enables people to maintain their bad practices brought over from raw SQL. I would like to see EF Core narrow that gap in performance a bit
- zip1234 6y ago
  We use a hybrid. Dapper is better for anything that needs optimized sql. CRUD is done with EF Core.
- bob1029 6y ago
  We exclusively utilize Dapper to talk to SQL. We came from EF6 and decided that the training wheels were getting in the way more often than it was worth. Performance was also abysmal but I am confident that has been improved dramatically for EF Core. In cases where we want to store really complex object graphs in SQL, we typically resort to JSON serialization of those objects. This allows for us to keep the important SQL facts in dedicated columns (i.e. for PK/constraints/indexing) and also have a copy of the full serialized POCO sitting in the last column for convenience. For reference, these databases (SQLite) are not shared with external parties/systems so we can get away with this sort of heavy-handed denormalization approach. Our use cases of the databases are very well bounded. In terms of migrations, we just write a simple for loop and use SQLite's user_version pragma to keep track of an incrementing integer version. This means that we actually have a superior solution to EF in that we don't need additional special metadata tables to keep track of this information.
  - philliphaydon 6y ago
    We started a new project at work, and one of the decisions was "No EF", altho we've pulled in some not so nice looking queries (mixed casing / indentation), the performance has been much better, and we can copy the query into management studio and check / optimize it. It's working out well. Part of the code reviews is asking how queries perform.
    - bob1029 6y ago
      Being able to validate SQL at code review time is really nice. Seeing the diff in GitHub between old vs new SQL can very quickly tip you off to troubles. Having your DB logic locked up in EF makes this kind of thing a lot more opaque. You could hypothetically develop a code review policy where developers are required to attach a query plan for each modified SQL statement to the PR. If the biggest problem is whitespace/casing in your SQL, you are probably sitting in a really good position. This is something we do try to be strict about. All of our SQL lives as string constants in 1 file per database so it is really easy to keep track of what is being used throughout in a consistent way. We do not permit developers to write SQL strings outside of these files. It all has to be in 1 place. We have 1 file for all SQL commands that will ever be used against that database, and a 2nd file for its schema migration scripts.

We saw about a 45% improvement in our API. EF Core also appears to have improved performance.

by skrowl 6y ago

We saw about a 45% improvement in our API. EF Core also appears to have improved performance.

Still slower than Dapper though? I like Dapper and we use it where I currently work, but it enables people to maintain their bad practices brought over from raw SQL. I would like to see EF Core narrow that gap in performance a bit

zip1234 6y ago
We use a hybrid. Dapper is better for anything that needs optimized sql. CRUD is done with EF Core.
bob1029 6y ago
We exclusively utilize Dapper to talk to SQL. We came from EF6 and decided that the training wheels were getting in the way more often than it was worth. Performance was also abysmal but I am confident that has been improved dramatically for EF Core. In cases where we want to store really complex object graphs in SQL, we typically resort to JSON serialization of those objects. This allows for us to keep the important SQL facts in dedicated columns (i.e. for PK/constraints/indexing) and also have a copy of the full serialized POCO sitting in the last column for convenience. For reference, these databases (SQLite) are not shared with external parties/systems so we can get away with this sort of heavy-handed denormalization approach. Our use cases of the databases are very well bounded. In terms of migrations, we just write a simple for loop and use SQLite's user_version pragma to keep track of an incrementing integer version. This means that we actually have a superior solution to EF in that we don't need additional special metadata tables to keep track of this information.
- philliphaydon 6y ago
  We started a new project at work, and one of the decisions was "No EF", altho we've pulled in some not so nice looking queries (mixed casing / indentation), the performance has been much better, and we can copy the query into management studio and check / optimize it. It's working out well. Part of the code reviews is asking how queries perform.
  - bob1029 6y ago
    Being able to validate SQL at code review time is really nice. Seeing the diff in GitHub between old vs new SQL can very quickly tip you off to troubles. Having your DB logic locked up in EF makes this kind of thing a lot more opaque. You could hypothetically develop a code review policy where developers are required to attach a query plan for each modified SQL statement to the PR. If the biggest problem is whitespace/casing in your SQL, you are probably sitting in a really good position. This is something we do try to be strict about. All of our SQL lives as string constants in 1 file per database so it is really easy to keep track of what is being used throughout in a consistent way. We do not permit developers to write SQL strings outside of these files. It all has to be in 1 place. We have 1 file for all SQL commands that will ever be used against that database, and a 2nd file for its schema migration scripts.