将虚拟机作为应用程序的一部分实现的主要好处是什么？
我最近研究的几个数据库在内部实现了虚拟机来执行各自的数据读取和写入。例如，请查看这篇关于 SQLite 虚拟机（他们称之为“VDBE”）的文章。我很好奇这样的架构有什么好处。我认为性能是其中之一，但为什么像这样的虚拟机运行得更快呢？事实上，这个额外的层似乎可能会导致它运行速度变慢。那么也许是为了安全？还是便携性？无论如何，只是好奇这个。
Several databases I've been looking at recently implement a virtual machine internally to perform the respective data reads and writes. For an example, check out this article on SQLite's virtual machine they call the 'VDBE'. I'm curious as to what the benefits of such an architecture are. I would assume performance is one but why would a virtual machine like this run faster? In fact, it seems to be that this extra layer could cause it to run slower. So perhaps it's for security? Or portability? Anyway, just curious about this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
它们在“类似汇编”的级别上完成工作，您可以在不损失可移植性的情况下获得可接受的速度。我认为他们提供了虚拟机，因此他们得到了平衡的权衡。要么将高级代码（SQL 代码**）作为高级语言执行，虽然会损失速度，但会获得便利。另一种方法是生成特定于平台（本机）的代码，与解释的代码相比，它的运行速度要快得多，但对于在 ANSI-C 存在的地方运行的广泛使用的库来说，这会带来很多麻烦。
** 当然，它不一定是 SQL 代码。我认为命令式表示更适合执行。无论如何，与“操作码”相比，该表示仍然是非常高级的表示。
They do their stuff at the "assembly-like" level, where you gain acceptable speed without losing portability. I think they provide a virtual machine so they get a balanced trade off. Either you execute the high level code(SQL code**) as a high level language and you lose speed but you gain convenience. The other way is to produce Platform-Specific(Native) code which is going to run much faster compared to the interpreted but it is a lot of hassle for a wide-spread library which runs where ANSI-C exists.
** It doesn't have to be SQL-code of course. I think that an imperative representation is much better suited for execution. Anyway, that representation still is a very high level representation compared to "opcode".