would i get any performance gains if i replace my data access part of the application from nhiberate to straight ado.net ?
i know that NHibernate uses ado.net at its core !
Short answer:
It depends on what kind of operations you perform. You probably would get a performance improvement if you write good SQL, but in some cases you might get worse performance since you lose the NHibernate caching etc.
Long answer:
As you mention, NHibernate sits on top of ADO.NET and provides a layer of abstraction. This makes your life easier in many ways, but as all layers of abstraction it has a certain performance cost.
The main case where you probably would see a performance benefit is when you are operating on many objects at once, such as updating many entities or fetching a large amount of entities. This is because of the work that the NHibernate session does to keep track of which objects are modified etc. My experience is that the performance of NHibernate degrades significantly as the amount of entities in the session grows.
NHibernate has a lot of ways to improve performance and if you really know it well, you can get it to perform quite close to ADO.NET. However, if you are not that familiar with it, you can easilly shoot yourself in the foot, performance-wise. (Select N+1 problem, etc.)
There are some situations where you could actually get worse performance when switching form NHibernate to straight ADO.NET. This is because of the fact that the NHibernate abstraction layer introduces some features that can improve performance, such as caching. NHibernate also includes functionality for optimizing the generated SQL for the current database management system. For example, if you are using SQL Server it might generate slightly different SQL than if you are using Oracle.
It is worth mentioning that it does not have to be an all or nothing kind of situation. You could use NHibernate for the 90% of your database access for which it works great, and then use straight SQL for the 10% where you do complex queries, batch inserts/updates etc.
Related
I am developing an application with laravel framework, and I want to measure orm query (CRUD) performance and compare it with RDBMS query performance.
I need to show that orm query performance is better than RDBMS but somewhere I read that eloquent laravel has a slow query performance. I need to make the right decision in order to show the desired result. Is doctrine better than eloquent ORM? And also which benchmark do you suggest me to use. I need these results for my thesis.
You're comparing apples to oranges here.
By definition, an RDBMS is always going to be faster, because the RDBMS is your database (RDBMS = Relational Database Management System). IE -- MySQL, SQL Server, PostgreSQL, etc. And the database does one thing really, really well -- handle data (okay, two things, depending on how you look at it -- storing and retrieving data).
Since every way of accessing the database from any other language is at least one step removed from the database itself, everything is slower than the RDBMS itself, if for no other reason than the language's interpreter has to first connect to the database at least once, before it can do anything.
That said, there are a few different layers available when dealing with databases in PHP:
Raw queries using PHP's built in mysql_* functions.
Basic database abstraction layers (ie - PDO)
Basic query builders (ie - Laravel's Query Builder)
Active Record pattern ORMs (ie - Eloquent)
Stateless/transactional ORMs (ie - Doctrine)
Assuming perfectly optimized queries fed into the given method by the developer, raw queries will be fastest, followed by the basic DBAL, followed by anything built on top of the basic DBAL. Where query builders and the ORMs built on them fall will depend on whether the query builder is, itself, built on top of another DBAL (in this case, I think it puts Eloquent one more layer removed than Doctrine, because Eloquent is built on Query Builder, which is built on PDO). This is because each one is an abstraction layer over the previous, so the path of the code, when executed, has to run through the stack.
The question then becomes how much of a difference are we talking? That depends entirely on the queries you're feeding into the system, as well as the quality of the system, itself. What are you looking for to show differences? How fast it can do a basic SELECT? Or how well it can do some crazy multi-JOIN query? What determines "speed" for the purpose of your thesis? Only you can really decide that, because you have more information than anyone here. For the sake of thoroughness, you're probably looking at basic SELECTs, complex queries that include things like JOINs, ORDER BYs, and GROUP BYs, and INSERT and UPDATE commands.
I will tell you this, though -- any test to show speed differences will likely have be on thousands or tens of thousands of transactions, at least, in order to show any significant differences, because on an individual transaction level, we're talking microseconds and possibly even nanoseconds in differences.
In actual industry use, then, how do we decide what route to go? Speed and ease of writing and maintaining the code. In that aspect, ORMs or DBALs will very often beat out raw queries. The fractions of a second per script run lost to the abstraction overhead is recuperated thousands upon thousands of times over in developer costs for time spent writing and maintaining the code in question.
In fact, by the time you get to the point where ORM vs DBAL vs raw queries actually matters, odds are good that you're starting to question whether your original database, language interpreter, or server is up to par with your software's demands. This is actually the issue that Facebook started facing a couple of years ago, at which point they started offloading some of their PHP to C, because C is faster in certain cases. It's also why they've created a completely new interpreter for PHP code (HipHop Virtual Machine, or HHVM), which is quite a bit faster than the original PHP engine.
I would appreciate it very much if you can help me with my questions:
Is EF5 reliable and efficient enough to deal with very large and complex dataset in the real world?
Comparing EF5 with ADO.NET, does EF5 requires significantly more resources such as memory?
For those who have tried EF5 on a real world project with very large and complex dataset, are you happy with the performance so far?
As EF creates an abstraction over the data access. Usage of EF introduces number of additional steps to execute any query. But there are workarounds to reduce the cost. As MS is promoting this ORM, i believe they are doing alot for performance improvement as well. EF 6 beta is already out.
There is good article on performance of EF5 available on MSDN for this.
http://msdn.microsoft.com/en-us/data/hh949853
I will not use EF if lot of complex manipulations and iterations are required on the DBsets after populating the DBSets from the EF query.
Hope this helps.
EF is more than capable of handling large amounts of data. Just as in plain ADO.NET, you need to understand how to use it correctly. Its just as easy to write code in ADO.NET that performs poorly. Its also important to remember that EF is built on top of ADO.NET.
DBSets will be much slower with large amounts of data than a code first EF approach. Plain Datareaders could be faster if done correctly.
The correct answer is 'profile'. Code some large objects and profile the differences.
I did some research into this on EF 4.1 and some details might still apply though there have been upgrades in performance to EF5 to keep in mind.
ADO vs EF performance
My conclusions:
-You won't match ADO performance with a framework that has to generate the actual SQL statement dynamically from C# and turn that sql statement into a strongly typed object, there is simply too much going on, even with pre compiled and 'warmed' statements (and performance tests conclude this). This is a happy trade off for many who find it much easier to write and maintain Linq in C# than stored procs and mapping code.
-You can still use stored procedures with equal performance to ADO which to me is the perfect situation. You can write linq to sql in situations where it works, and as soon as you would like more performance, write the sproc and import it to EF to enjoy the best performance possible.
-There is no technical reason to avoid EF accept for the requirements of your project and possibly your teams knowledge and comfort level. Be sure to make sure it fits into your selected design pattern.. EF Anti Patterns to avoid
I hope this helps.
I see a ton of examples for MVC DAL with entity framework, but nothing for ADO.NET and stored procedures?
There seems to be a trend on the "Repository" pattern and "UnitofWork" for creating a DAL, similar to this:
http://www.codeproject.com/Articles/207820/The-Repository-Pattern-with-EF-code-first-Dependen
How would I migrate this codebase away from EF to ADO.net stored procedures?
How would I migrate this codebase away from EF to ADO.net stored procedures?
You have gotten very few answers as most of us are moving away from stored procedures.
The two biggest reasons for that are:
Control over the business logic
Having all the business logic in one place makes it easier to read the code, and therefore maintain the application. i.e. you get a muc better flow when programming.
If you spread out the business logic between SPs and .NET code you have to mentally shift (store state) each time to switch between code and SPs.
Easier to test
Testing is important. Especially for applications which have a maintenance plan.
For .NET there are several tools for testing your code. Everything can be tested in isolation (without external dependencies) with little effort, and there are several articles describing different test techniques.
Testing stored procedures in isolation is hard.
Myth: Stored procedures is faster than SQL queries.
Today stored procedures do not have a performance gain over parameterized queries (i.e. queries that uses arguments as #userName) as they did a couple of years ago (SQL Server 2000 and below). They should infact have similar performance as the execution plan is now saved for parameterized queries too.
However, if you have logic in your SP:s which process the result from multiple queries they DO get better performance as no roundtrip between your application and the database server is required. But the can easily be compensated by different application architecture.
Conclusion
Think twice before going down that path. It's usually not worth it. What you gain (money) in less CPU cycles is typically a lot less than the amount of hours spent on creating and maintaining the application.
That said, stored procedures can be used as instructed here: http://msdn.microsoft.com/en-us/data/gg699321.aspx
I have search the internet high and low looking for any performance information for LLBLGen Pro. None found. Just wanted to know how does LLBLGen Pro perform compared the Nhibernate. Thanks
Your question is essentially impossible to answer without context. The questions I would ask in response would start with:
What kind of application? Data-centric? Business logic-centric?
How much data are we talking about?
What kind of data operations are we talking about? Mostly reads? Mostly writes?
As a general matter, LLBLGen performs very well. We have used it on 10+ projects (including a few enterprise-scale projects) where I work, and the few issues we've seen with performance were always the result of misunderstand what the code was doing (there is a learning curve) or a poorly implemented physical model (e.g. missing indexes).
The two frameworks approach the problem of data access very differently. LLBLGen's operations generally translate into SQL that is fairly easy to understand if you have a strong data background. NHibernate uses sessions and cache to keep data in memory when possible to improve performance (disclaimer: I am not an NHibernate expert). LLBLGen does not support this sort of concept; instead it works in a disconnected state and stores change tracking information directly on its entity objects.
Bottom line, the approaches the frameworks take are very different, and it's hard to predict which will perform better without knowing more about what your system does. In the right hands, either framework can be used to design a system where data access performance is not a major performance bottleneck.
Initially we tested LLBLGen # ORMBattle.NET, it was ~ 2 times faster than NH on materialization; LINQ query compilation time was pretty good (~ 4000 queries/sec.), but CUD operations were noticeably slower than in NH (there is no CUD batching in LLBLGen).
Both frameworks must be relatively slow in case when you deal with large amount of objects in the same session:
NH is relatively slow because of its materialization pipeline. I'm not fully sure why, but e.g. to implement dirty checking, NH must store a clone of any materialized objects somewhere. At least two times more RAM ~= at least 2 times slower.
LLBLGen uses relatively "fat" entities - it seems they store fields in dictionaries. Obviously, this isn't good from the point of performance, since RAM consumption is one of essential factors affecting on it.
See this FAQ question and Test Suite Summary for a bit deeper explanation.
So in short, LLBLGen Pro must be faster than NH on reads, but slower on writes.
Given a straightforward user-driven, high traffic web application (no fancy reporting/BI):
If my utmost goal is performance (not ease of maintainability, ease of queryability, etc) I would surmise that in most cases, a roll-yourown DAL would be the best choice.
However, if i were to choose Linq2SQL or NHibernate, roughly what kind of performance hit would we be talking about? 10%? 20%? 200%? Of the two, which would be faster?
Does anyone have any real world numbers that could shed some light on this? (and yes, I know Stackoverflow runs on Linq2SQL..)
If you know your stuff (esp. in SQL and ADO.NET), then yes - most likely, you'll be able to create a highly tweaked, highly optimized custom DAL for your particular interest and be faster overall than a general-purpose ORM like Linq-to-SQL or NHibernate.
As to how much - that's really really hard to say without knowing your concrete table structure, data and usage patterns. I remember Rico Mariani did some Linq-to-SQL vs. raw SQL comparisons, and his end result was that Linq-to-SQL achieve over 90% of the performance of a highly skilled SQL programmer.
See: http://blogs.msdn.com/ricom/archive/2007/07/05/dlinq-linq-to-sql-performance-part-4.aspx
Not too shabby in my book, especially if you factor in the productivity gains you get - but that's the big trade-off always: productivity vs. raw performance.
Here's another blog post on Entity Framework and Linq-to-SQL compared to DataReader and DataTable performance.
I don't have any such numbers for NHibernate, unfortunately.
In two high traffic web apps refactoring a ORM call to use a stored procedure from ado.net only got us about 1-2% change in CPU and time.
Going from an ORM to a custom DAL is an exercise in micro optimization.