I'd be incredibly surprised if mobile power management did not account for the difference between "blitting array of 2D pixels" and "running massively parallel shader". Even if not done for energy conservation, it might be for TDP profile.
Separately, it's long been a thing on Nvidia Optimus laptops where the most inexplicable thing could cause the iGPU to be swapped out for the power-hungry discrete GPU. A GL-powered terminal definitely seems like it could be in that territory.
In short, many reasons it could be less efficient, hence the question, is there any evidence that it /is/ less efficient?
Is there any indication of the energy impact using a GL context to render plain old text? These concepts seem incompatible in the context of a laptop, and who needs GL here when the bottleneck is biological. One of my favourite working modes is shutting down everything and just hacking away in vim, partly for distraction management but primarily because of battery.
Nothing to add to the conversation, just wanted to say I absolutely adore this. Years ago I used to think it'd be nice if search engines simply exposed all their shards to clients and let clients do all the results merging and suchlike. Of course that's probably a terrible idea in practice for performance, but this library is definitely implementing the spirit in a very practical way!
It also reminded me of a vague inverse of this hack. In old versions of Qemu (possibly it is still implemented, but I have vague memories it got ripped out), you could point Qemu at a directory on disk and it'd produce an emulated floopy disk drive with a virtual FAT12 image containing the directory contents. AFAIK it didn't keep the actual data in memory, I guess all it needed was file sizes to know how to build a virtual memory mapping that contained the filesystem metadata + proxied reads from the underlying files for data sectors. I look forward to seeing your implementation of this concept in a virtualized SQLite file <-> GraphQL proxy ;)
Both the index and table data are btrees. These are trees - the root node sits in some known location (offset) in the file, referenced by the file header and metadata. As SQLite traverses the tree, it encounters new descendents it would like to visit, presumably identified by their byte offset in the file, which is all needed for this VFS magic to issue a suitable range request.
- SQlite opens the file and reads 4kb worth of header -> range request for byte 0-4096
- headers/metadata refers to index table with root node at 8192kb
- user issues SELECT * from index WHERE name = 'foo'
- SQLite reads root node from the file (range request for 8192kb..)
- Root node indicates left branch covers 'foo'. Left branch node at address 12345kb
- Fetch left branch (range request for 12345kb)
- New node contains an index entry for 'foo', row 55 of data page at 919191kb
- SQLite reads data page (range request for 91919191kb..)
Separately, it's long been a thing on Nvidia Optimus laptops where the most inexplicable thing could cause the iGPU to be swapped out for the power-hungry discrete GPU. A GL-powered terminal definitely seems like it could be in that territory.
In short, many reasons it could be less efficient, hence the question, is there any evidence that it /is/ less efficient?