I tried asking this question on stack-overflow. I am interested in having two (or more) KDB instances using a read-only table loaded into shared memory. My requirement is to load the data(table) once and cache it there. If I were able to put the table into read-only(immutable) mode, multiple readers can use the data without
again loading the data from disk.
Thank you for your reply. If I understood correctly, your solution relies on
OS page caching?
Is there true shared memory space where I can instruct KDB instances that table X is laid out at the offset Y
and should be treated as effectively read-only?
OS page cache is implicit and could be swapped out by OS depending
on system utilization. I wanted to build an in-memory caching layer where multiple KDB “compute” instances
share table(s) and reduce disk I/O because data is pre-loaded for them. I want to be in full control of
caching and I/O.
Charles, I could discuss my use case offline if you’re interested at all?
It looks like d9(b9(-1,x) is a (or the only?) nul-safe way of doing deep-copy of types 0, KS, XT, XD using C API? (It is a neat way, albeit expensive.)
Speaking of C API, there is no mention of API for retrieving number of bytes a K object takes up. TorQ’s objsize function is useful from q and it can be called via k(), but it’d be more convenient to have a C function.
there would be a small recursive answer in q using count, type and a map of types to size. only problem is that where lists share references to other objects, you will find that the total size of all objects sum to greater than process memory usage. once the q function is known, it can be translate to c - or just call k(0,“{my small size function}”,r1(x)) if you’re in a shared object.
but if you want to know how much memory an object uses in q’s memory allocation method (http://code.kx.com/wiki/DotQ/DotQDotgc), each list size will have to be rounded up to the next larger memory block.