HttpContext.Current.Items 访问项目的速度太快，但是如何实现？
我写了简单的测试
- 添加100个项目到[Collection]
- 随机从[Collection]读取1000000次
当
- [Collection]==HttpContext.Current.Items需要50毫秒
- [Collection]==HttpRuntime.Cache需要430ms
- [Collection]==哈希表 || [Collection]==Dictionaty 170ms
我猜 HttpRuntime.Cache 的开销是同步的
我尝试更改 HashTable/Dictionary 的初始容量？但没有成功。
有谁知道这个turbo HttpContext.Current.Items 的原因是什么？ 我可以创建这种对象来自定义缓存实现（当然带有同步暗示）。
I wrote simple test
- add 100 items to [Collection]
- read 1000000 times from [Collection] randomly
When
- [Collection]==HttpContext.Current.Items it takes 50 ms
- [Collection]==HttpRuntime.Cache it takes 430ms
- [Collection]==HashTable || [Collection]==Dictionaty 170ms
I guess the overhead of HttpRuntime.Cache is sync
I try to change initial capacity of HashTable/Dictionary? but with no success.
Does anyone know what is the reason of this turbo HttpContext.Current.Items?
May I create this kind of object to custom cache implementation(of course with sync imply).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
缓存缓慢的原因是它是线程安全 - 正如您所猜测的。
HttpContext.Current.Items的基础类型是一个普通的Hashtable。也许如果你放一段代码，我就能解释与第三项的区别。The reason cache is sluggish is because it is thread safe - as you guessed.
Underlying type for
HttpContext.Current.Itemsis a plainHashtable. Perhaps if you put a snippet of your code, I would be able to explain the difference with the 3rd item.