为什么EF6.1.3分离实体性能错误低下

为什么EF6.1.3分离实体性能异常低下？
db.Entry<T>(item).State = EntityState.Detached;

刚从EF4升级到EF6，
数据要做缓存，循环分离实体，性能异常低下
三千多条数据要耗时几十秒
用EF4的时候只需要数毫秒，不是说EF6性能有很大提升吗？
为什么会这样？

请问有没有其它的方法？
------解决思路----------------------
DBContext/ObjectContext都应该用完销毁的吧。对于缓存场景，取完需要的数据之后，销毁相关的DBContext就好了吧，不用多此一举把DBContext里的StateManger里的状态都改掉。难道你的DBContext还是大家公用的？这样访问量上来之后貌似就有问题了
------解决思路----------------------
真的提高性能了么？只有在你一次请求的过程中，反复/多次查询相同的数据才有提高性能的可能吧，而且还是利用了EF的缓存机制的。
撇开这个问题不说，你现在是为了加载缓存，这个逻辑和普通的数据查询是不同的，不应该归在普通的一次请求的流程中吧。（虽然这是某次请求的时候触发的），完全可以把构建缓存的逻辑独立出来，独立于你设定的一次请求只用一个DBContext
------解决思路----------------------

引用:

Quote: 引用:

真的提高性能了么？只有在你一次请求的过程中，反复/多次查询相同的数据才有提高性能的可能吧，而且还是利用了EF的缓存机制的。
撇开这个问题不说，你现在是为了加载缓存，这个逻辑和普通的数据查询是不同的，不应该归在普通的一次请求的流程中吧。（虽然这是某次请求的时候触发的），完全可以把构建缓存的逻辑独立出来，独立于你设定的一次请求只用一个DBContext

性能还是有提升的，声明一个dbcontext和数十个甚至数百个，不仅仅是dbcontext 更重要的是对象的connection，只打开一次数据库连接和多次打开数据库连接区别还是很大的。把缓存的独立也是一种解决方法

区别不是connection，connection只有每次做实际查询和save的时候才会open，平时都是close的，这个就回到最基础的ADO.NET的connection是不是需要共享这样的问题上了（你可以把DBConext里的Connection放到监视里看看它的state状态变化情况）。公用dbcontext最大的提升还是在于已查询过的数据被缓存起来供下次调用。