Is there any use case where safe_fixtable/2 must be used?
1 Like
In ETS at least, safe_fixtable protects you from seeing concurrent changes that happen when you loop over the table using e.g. with first, next and so on.
The manual mentions you must use it for dets:match/3:
The table is always to be protected using safe_fixtable/2 before calling match/3, otherwise errors can occur when calling match/1.
The same note can be found for select/3 and select/1.
However in contrast to ETS it seems DETS does not seem to have the same guarantees in regards to safe_fixtable as ETS, see the safe_fixtable function documentation
1 Like
Thank you jchrist.
As it stands, I read this as: if processing requires a high degree of concurrency, the use of
dets:match/1,3 dets:select:1,3 may seriously degrade overall performance of the system in presence of inserts.
Thus, (after combining what I’ve read for safe_fixtable) it appears that any performance gained by using match and select may be lost in concurrent environment with a lot of inserts and deletions.
So, how wrong would I be if I say that systems which require considerable amount of continuous inserts and deletions should rather use first and next (even if it requires more work on your part)?
2 Likes
I can’t make a general statement on DETS performance - I haven’t used it directly myself and as always the best idea is to benchmark your usecase 
I believe you can circumvent the errors that match and select are documented to have without safe_fixtable with these functions, but then you need to traverse the entire table and are carrying the overhead of having to read and parse every element individually. But again, benchmark, maybe it works for your usecase.
Also re-reading your questions: if you do require fast in-memory lookups in plain Erlang with persistence then Mnesia will probably do what you want: you (can) get the performance of raw ETS and Mnesia’s transaction logging facilities (via disk_log) make sure that your data is safe on disk. Plus, you get to choose if you want isolation from concurrent updates via transactions, or raw speed via dirty access. I wrote an Mnesia benchmarking tool the other day if you want to test how the different access methods perform with different configurations.
Hope this helps!
1 Like
Hmmm… no thank you.
1 Like