HackerPapers

arXiv:1512.03207cs.PL

Making an Embedded DBMS JIT-friendly

Carl Friedrich Bolz, Darya Kurilova, Laurence Tratt

Abstract

While database management systems (DBMSs) are highly optimized, interactions across the boundary between the programming language (PL) and the DBMS are costly, even for in-process embedded DBMSs. In this paper, we show that programs that interact with the popular embedded DBMS SQLite can be significantly optimized - by a factor of 3.4 in our benchmarks - by inlining across the PL / DBMS boundary. We achieved this speed-up by replacing parts of SQLite's C interpreter with RPython code and composing the resulting meta-tracing virtual machine (VM) - called SQPyte - with the PyPy VM. SQPyte does not compromise stand-alone SQL performance and is 2.2% faster than SQLite on the widely used TPC-H benchmark suite.

arXiv comments
24 pages, 18 figures
Journal reference
DOI
Subjects
cs.PLProgramming Languages cs.DBDatabases

On Hacker News

Linked by 2 identifiable commenters in 3 comments across 3 threads, from May 2016 to Jan 2017.

Comments linking this paper, per year.

Discussed in comments3 threads

  1. 2.2 seconds to insert a million rows in the browser with WebAssembly+Web Workers 1 comment

    • Posting this mainly for the "fused VM" idea that I have seen floating around here: Having the language and the systems it talks to fused by a JIT that eliminates the communication overhead; which is something that (does?|can?|could?|will?) happen in this case. This is in the…

      BenoitPView on HNParent context

  2. JVM JIT optimization techniques 1 comment

    • > I don't know anyone who would say the majority of Java applications aren't huge, slow, memory-hogging beasts compared to equivalent native ones, and whose codebases are just as unoptimised for the perspective of the humans who have to work with them. I would, and I've been…

      pronView on HNParent context

  3. Open-Sourcing Twitter Heron 1 comment

    • Aside from Erlang which is far too slow (most Erlang apps use C for the data plane) the others are far too risky choices in terms of hiring, future support and general maintainability. Also there are far too many unknowns about them. Rust shows a lot of promise and may very well…

      pronView on HNParent context

Submitted to Hacker News

Connected through shared HN threads, not inferred similarity or a recommendation.