@hyc
To be completely fair, SQL requires you to convert to and from string representation the whole time. If performance *really* matters, anything SQL-based is a mistake
@Archivist
To be completely fair, SQL requires you to convert to and from string representation the whole time. If performance *really* matters, anything SQL-based is a mistake
@Archivist
@bert_hubert
You mean like https://www.sqlitetutorial.net/sqlite-blob/, correct?
Your SQL engine would still be involved, and needs to do string parsing just to understand what it is you want to store in binary. Yes it's faster than converting to base64 and back, but not as fast as a memcpy ala LMDB.
I said "*really*" for a reason 😉
@hyc @Archivist
You mean like https://www.sqlitetutorial.net/sqlite-blob/, correct?
Your SQL engine would still be involved, and needs to do string parsing just to understand what it is you want to store in binary. Yes it's faster than converting to base64 and back, but not as fast as a memcpy ala LMDB.
I said "*really*" for a reason 😉
@hyc @Archivist
- replies
- 1
- announces
- 0
- likes
- 0
@bert_hubert
I didn't mean to offend, but "sqlite can't be as fast as LMDB because of its design choices" is the statement *I* was trying (but perhaps failing) to make.
That doesn't make those design choices invalid -- in most cases I prefer SQL for ease of debugging -- but if performance *really* matters, LMDB is really the only option.
That doesn't mean 'everything else is slow', just that LMDB is faster
@hyc @Archivist
I didn't mean to offend, but "sqlite can't be as fast as LMDB because of its design choices" is the statement *I* was trying (but perhaps failing) to make.
That doesn't make those design choices invalid -- in most cases I prefer SQL for ease of debugging -- but if performance *really* matters, LMDB is really the only option.
That doesn't mean 'everything else is slow', just that LMDB is faster
@hyc @Archivist