3 ms·
There’s nothing obvious is linked release but is this expected to have an affect on performance either good or bad?
by Lio 5y ago
There’s nothing obvious is linked release but is this expected to have an affect on performance either good or bad?
- SQLite 5y agoThe SQLite dev's internal performance testing using cachegrind shows that STRICT mode uses about 0.34% more CPU cycles. So STRICT is slightly slower, but not enough that you could measure the difference reliably in a real-world system.
- ripley12 5y agoI wouldn't expect much difference in performance. "The on-disk format for the table data is the same." I would expect the additional checks on writes to be negligible in most cases (dwarfed by other bookkeeping and I/O). I imagine that strict mode could enable some optimizations for read queries, but I can't see those being huge wins.
- ComputerGuru 5y ago> but I can't see those being huge wins. I agree from an algorithmic perspective but in the real world, it really depends. The size of a non-text/binary cell within a column is now fixed, meaning guaranteed to never need to resize/reallocate when streaming results. That could translate to non-negligible improvements (multiple percentage point speed up) if it’s implemented separately from the existing code path.
- prirun 5y ago> The size of a non-text/binary cell within a column is now fixed I think this is not true since the on-disk format didn't change, ie, ints are still variable-size whether strict or not.
- ComputerGuru 5y agoThe format/spec doesn’t change, the implementation does. “This field can be variably sized” vs “but in practice since this is a strict table it will always be exactly n bytes”
- ComputerGuru 5y agoIt’s really no more than an additional (hyper optimized) check constraint on the type; with branch prediction it’s probably ~free.