architectural guidance

[giacomociti]

Hello, I'm asking here for general architectural guidance.

I'm developing an API that provides RDF data from a triple-store and calculations over such data performed with Eye.
The expressivity of the reasoner is amazing, but I'm trying to figure out some performance optimizations around its interface.

I'm using the eye-js distribution because the API is developed using node (but similar considerations may apply also if using the native Eye).

The main overhead is that, for each API request, a new module is instantiated and it's necessary to parse not only the input data but also the rules, as well as a considerable amount of data coming from the database. For the latter, using --turtle (as suggested here) is a tangible improvement but still not sufficient.

I see two alternatives here: one is to create a PVM as suggested here (I tried and got excellent performance with the native Eye but I'm not sure if this is possible with eye-js), and the other is to avoid loading the database triples up-front and leveraging log:semantics to load on-demand (based on the rules actually triggered by input data) only the data needed by the request at hand (arguably a small fraction).

Another aspect is scalability: I haven't tried it yet but I'm afraid instantiating a new module for each request is not scalable (especially if each module includes a considerable amount of data).
I'm wondering about module reuse (either concurrent or with some kind of pool). I guess reusing a module will grow in time its memory footprint: even though we use --query, I don't think the intermediate derivations performed to answer the query are discarded.

To sum it up, I hope you can provide some suggestions or simply point out some misconceptions. And thanks for your awesome work.

[jeswr]

PVM as suggested #2 (I tried and got excellent performance with the native Eye but I'm not sure if this is possible with eye-js)

eye-js is already using a pvm to start-up. All you would need to do is use functions like https://github.com/eyereasoner/eye-js/blob/b135f42f61f47673529f875bacd57ea48d8d23dc/lib/transformers.ts#L24-L38 and switch out the EYE_PVM const for the contents of the pvm that you generate. Happy to talk you through this in more detail if you go down that road.

Another aspect is scalability: I haven't tried it yet but I'm afraid instantiating a new module for each request is not scalable (especially if each module includes a considerable amount of data).

Rest assured that node is pretty good at cleaning up memory when the module goes out of scope. This memory test is ensuring that NodeJS' memory consumption does not increase indefinitely when using the n3reasoner function (which internally creates a new SWIPL module for each function call).

and the other is to avoid loading the database triples up-front and leveraging log:semantics to load on-demand (based on the rules actually triggered by input data) only the data needed by the request at hand (arguably a small fraction).

Note that you will still need to load all of your data into the virtual WebAssembly file system up-front in order for it to be accessible to eye.

I'm wondering about module reuse (either concurrent or with some kind of pool). I guess reusing a module will grow in time its memory footprint: even though we use --query, I don't think the intermediate derivations performed to answer the query are discarded.

This depends on the kind of cleanup that eye does withing a single use so I'll defer to @josd on this one. You could also run your on perf tests here. (You can base it on https://github.com/eyereasoner/eye-js/blob/main/__tests_memory__/leakTest.js, but rather than calling n3reasoner each time, execute another query on the same module).

[josd]

This depends on the kind of cleanup that eye does withing a single use so I'll defer to @josd on this one. You could also run your on perf tests here. (You can base it on https://github.com/eyereasoner/eye-js/blob/main/__tests_memory__/leakTest.js, but rather than calling n3reasoner each time, execute another query on the same module).

Till EYE v3.x.y we did complete cleanup when using --multi-query but we dropped --multi-query in EYE v4.x.y and the best you can do is restarting eye per new query.

[giacomociti]

thanks @jeswr, I started looking at transformers.ts. So I guess I have to generate something like eye.ts but including also my rules and static data. This led me to swipl-wasm/dist/generateImage where I got lost in the internals: seems like generateImageBuffer
is passing only -q, -f, and the Prolog file, so I don't know how to include also my rule and data.

I could create a pvm with the native eye using a command like the folllowing:

swipl -q -f /usr/local/src/eye.pl -g main -- --nope ./my-rule.n3 --turtle ./my-data.ttl --image my-image.pvm

[jeswr]

You'll want to execute the command in https://github.com/SWI-Prolog/npm-swipl-wasm/blob/6389671ef69634212deb3a6344484d73f371736c/dist/generateImage.ts#L24 by running the command Module.prolog.query("main(['--nope', './my-rule.n3', '--turtle', './my-data.ttl'])").once() there.

You will need to load my-rule and my-data into the virtual filesystem in the pre-ceding line. The code to do this will look similar to https://github.com/eyereasoner/eye-js/blob/072c07bfcee67ea5c3fe5116b185ce225f1d4e85/lib/bin/main.ts#L12.