← Back to context

Comment by ori_b

5 years ago

> If you have an FPS or interactivity target that needs to be guaranteed to be better than about 0.1-1 second - depending on platform - you can't have any disk IO at all on the UI thread, or any thread that's supposed to react at interactive rates at all times.

Yes, and other file formats encourage doing things in memory, so you don't have any disk i/o in the common path.

Using sqlite as a file format strongly discourages the simple, jank-free until you press save workflow of slurping your content, operating on it in memory, and then outputting it all in one operation as a response to an explicit user action. Instead, your whole application gets small but perceptible delays across all operations and interactions.

8 comments

ori_b

Reply
lxdesk  5 years ago

That conflates the use of the schema with the use of the format features. You can, in fact, use your custom in-memory structures and then "slurp it out" to BLOB when you're ready to save.

  • ori_b  5 years ago

    Yes. But if you go that way, though, sqlite is just a slow and clunky format compared to, eg, json or protobuf. I doubt that any program out there uses sqlite this way, other than those which realize they painted themselves into a performance corner and hacked around it for compatibility.

em500  5 years ago

Your concerns seem pretty theoretical. Several very widely used applications (Whatsapp, iMessage, Apple Notes/Calendar) use sqlite as a file format without much issue.