3 ms·
EF is slow, IMX. But I think it mainly has to do with the fact that it's an ORM, and since the application un-marshals to objects and marshals back to the data
by da_chicken 5y ago
EF is slow, IMX. But I think it mainly has to do with the fact that it's an ORM, and since the application un-marshals to objects and marshals back to the data store more or less one object at a time, you lose set-based operations. If you're interacting with a lot of discrete, unrelated objects, that gets really inefficient. You can easily end up with the dreaded "row by agonizing row" pattern:
UPDATE Student SET Grade = '04' WHERE StudentId = '12345'
UPDATE Student SET Grade = '04' WHERE StudentId = '12346'
UPDATE Student SET Grade = '04' WHERE StudentId = '12347'
UPDATE Student SET Grade = '04' WHERE StudentId = '12348'
.
.
.
.
UPDATE Student SET Grade = '04' WHERE StudentId = '12349'
Instead of:
UPDATE Student SET Grade = '04' WHERE StudentId IN ('12345','12346','12347','12348', ...., '12349')
- smackeyacky 5y agoOh it can be slow, not all of the entity framework adaptors support bulk operations. I ended up extending it a bit on my object model to include bulk operations which do pretty much what you have there (I stuck to delete and insert though). However, I have used a pile of ORM products since the early C++ / smalltalk days back in the 1990s and it's easily the best ORM I've ever used.