4 ms·
You can dynamically load/unload shared libraries so the data is only shared once between all processes. A win is you can also optimize the memory layout of the
by toddh 13y ago
You can dynamically load/unload shared libraries so the data is only shared once between all processes. A win is you can also optimize the memory layout of the translation tables (can be in C), for which a hash is probably not optimal. This can all be automated in the build process using the database as a source. During software upgrades processes must be aware enough to know when to reload. And since all shared memory schemes use virtual memory you still have potential latency issues because of paging. Not sure if a .so can be pinned. Another win is it is read only so you don't have to worry about corruption.
- jtai 13y agoOur community of translators update translations all the time. Updates are immediately reflected so that our translators have instant feedback, and we'd like our users to see the updated translations sooner than every time we deploy too. So that rules out a purely build-time solution for us.
- toddh 13y agoI guess build time is a bit of a misnomer. Any time changes occur, perhaps they aggregated for an hour, the files are rebuilt and redistributed. Since the API doesn't change it doesn't require changes in the process code, just the shared lib. But I understand, it was just a thought that fit the given criteria.