17 ms·

Another option is to adapt a database engine to support page-aligned blobs, which is probably not that hard to achieve.

• stillpointlab 23d ago
  Of course there are many options, but the benefit of the SQLite approach is the existing tooling, support, etc. Like others have said, one could just write a SQL interface over a set of virtual tables derived from the actual elf (if one just wanted a CRUD-like interface to a binary). All of the benefits of SQLite disappear once one diverges from the format in any way. At which point it would be better to ask: "what is the best first-principles implementation of this idea?", instead of "what is the minimal change to SQLite to achieve this specific narrow goal?"
• setheron 23d ago
  I might look at this next; with Nix it's easy to explore and rebuild seamlessly ;P
  • hedgehog 23d ago
    I didn't understand the core issue, is it that due to non-alignment of the on-disk data you have to do a copy at load time, but if you could guarantee alignment of the actual blob content then you could use it directly?
    • garganzol 23d ago
      Exactly, a guaranteed alignment and continuity of a blob makes it memory-mappable allowing to avoid copying the data back and forth.
      • hedgehog 22d ago
        On a brief background read it looks like another issue is that blobs are not necessarily stored in contiguous regions of the file. Maybe there's some clever way to combine a VFS shim and virtual tables to store page aligned blobs in a region of the same file as the main database.