预加载与使用 PHP、SQLite 的许多查询
我有一个存在 n+1 查询问题的应用程序,但是当我实现一种急切加载数据的方法时,我发现绝对没有性能提升。 我确实使用了身份映射,因此对象仅创建一次。
这是约 3000 个对象的基准。
first query + first object creation: 0.00636100769043 sec.
memory usage: 190008 bytes
iterate through all objects (queries + objects creation): 1.98003697395 sec.
memory usage: 7717116 bytes
这是我使用急切加载时的情况。
query: 0.0881109237671 sec.
memory usage: 6948004 bytes
object creation: 1.91053009033 sec.
memory usage: 12650368 bytes
iterate through all objects: 1.96605396271 sec.
memory usage: 12686836 bytes
所以我的问题是,
- 当涉及小型查询时,SQLite 是否神奇地快如闪电? (我习惯于使用 MySQL。)
- 这对任何人来说都是错误的吗? 急切加载不应该提供更好的性能吗?
I have an application that has an n+1 query problem, but when I implemented a way to load the data eagerly, I found absolutely no performance gain. I do use an identity map, so objects are only created once.
Here's a benchmark of ~3000 objects.
first query + first object creation: 0.00636100769043 sec.
memory usage: 190008 bytes
iterate through all objects (queries + objects creation): 1.98003697395 sec.
memory usage: 7717116 bytes
And here's one when I use eager loading.
query: 0.0881109237671 sec.
memory usage: 6948004 bytes
object creation: 1.91053009033 sec.
memory usage: 12650368 bytes
iterate through all objects: 1.96605396271 sec.
memory usage: 12686836 bytes
So my questions are
- Is SQLite just magically lightning fast when it comes to small queries? (I'm used to working with MySQL.)
- Does this just seem wrong to anyone? Shouldn't eager loading have given much better performance?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
你的“问题”的一部分是 SQLITE 在小查询上快如闪电!
“问题”的另一个症状是因为 SQLITE 是嵌入式代码
访问单个本地文件没有任何正常开销
编组参数、通过网络发送、打开表
空间文件,编组回复等,你用沉重的
数据库。
Part of your "problem" is SQLITE is lightning fast on small queries!
The other symptom of the "problem" is because SQLITE is embedded code
accessing a single local file there is none of the normal overhead of
marshalling parameters, sending over the network, opening table
space files, marshalling replies etc. that you get with a heavy
database.