Question: We have a point-of-sale system that was developed using ado.net, our current concern is to make the application real fast in creating transactions (sales). Usually there are no performance concerns with high end PCs but with with low end PCs, the transactions take really slow.

The main concern is on saving transactions which usually calls a lot of stored procedures for inserting records within a single transaction. This usually takes time on low end PCs. We need to improve the performance since most clients will only use low end PCs to act as cashier machines. One solution we are thinking is to use entity framework for data access. The entire project is written using ado.net and development time if we shift to entity framework would be alot. Any suggestions?

Answer: 
I would like to point out that Entity Framework (full name: [ADO.NET Entity Framework](http://msdn.microsoft.com/en-us/library/bb399572.aspx)) is an ORM (Object Relational Mapper) that uses ADO.NET under the hood for connecting to the database. So the question "should we use ADO.NET or EF?" doesn't really make sense in that respect. Unless you re-architect your application, adding EF to the mix is simply adding another layer on top of ADO.NET. 

I sincerely doubt that ADO.NET is the source of your performance problems, however. It sounds like the problem exists in your stored procedures themselves. 

I think [Luc Franken's comments](https://softwareengineering.stackexchange.com/questions/203829/ado-net-or-ef-for-a-point-of-sale-system#comment398288_203829) are on the right track, though. You need to measure and determine exactly where the delays are happening. Then concentrate on fixing exactly that problem. Anything else is groping around in the dark.
You say you are calling a "lot of stored procedures". If every call includes a seperate trip to the database, that is your performance issue, because trips to the database are always expensive, no matter what they do. You should have one stored procedure to save a transaction. If that procedure has to call other procedures, fine, as long as you don't have to make a seperate trip to the database.