Re: sqlite3

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> But a "proper" database might give other advantages like a faster
> search in the loaded data (unless it's already "indexed" by using hash
> tables everywhere where they could be used).
>
> Or being able to read the data without loading the whole file into
> memory. Which, for certain scenarios and data sets, might be a bigger
> advantage than faster writes.

Here's a matrix of advantages and disadvantages to three approaches:
sqlite, one-file-per-value, and
one-file-with-a-hash-table-with-several/all-values:
  
                           sqlite  files  hash
Read/write value speed     ⚄       ⚅     ⚀
Read/write value mem       ⚅       ⚄     ⚀
List all values speed      ⚅       ⚀     ⚅
List all values mem        ⚃       ⚁     ⚃
Ease of moving around      ⚄       ⚀     ⚅

>> But it turns out that sqlite3 is actually slower for this particular use
>> case than just writing the data to a file (i.e., using the file system
>> as the database; one file per value).  So multisession.el now offers two
>> backends (`files' and `sqlite'), and defaults to `files'.
>
> Does the latter scenario use as many files as you do 'COMMIT' in the
> former scenario?

No, if you (cl-incf (multisession-value foo)) you'll get one COMMIT per
time, but there'll only be one foo.value file (at a time).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no