Open rubensworks opened 2 years ago
Haven't seen this yet @rubensworks - definitely worth a try - I suspect the performance issues in the AsyncIterator package need to be released before these components will be competitive in it
I just tested the following segment
const { Parser, Store } = require('n3');
const fs = require('fs');
const parser = new Parser();
const store = new Store();
const now = performance.now();
parser.parse(fs.createReadStream('./tbox.ttl'), (e, quad) => {
if (!quad) {
const end = performance.now();
console.log(end - now, store.size);
return;
}
store.add(quad)
})
it takes 21s (and if we don't load it into the store it is 5s), so the time to parse and add
data in the N3 package still needs to be improved in order to be competitive with loading times accounted for @rubensworks @RubenVerborgh
it takes 21s (and if we don't load it into the store it is 5s),
So that's just for parsing and loading, right?
Based on the loading times reported in that gist (6s, 36m, 2m), that seems quite competitive though.
So that's just for parsing and loading, right?
Yep
that seems quite competitive though.
True (I was only comparing to the 6s one) - though it would be nice if it could be brought closer to the 1sec state-of-the-art of RDFOX
True (I was only comparing to the 6s one) - though it would be nice if it could be brought closer to the 1sec state-of-the-art of RDFOX
This is JavaScript though; we don't have the low-level access that they do. I suspect most of the time is storage, not parsing.
There's also the hidden variable of different system capabilities to take into account here. Good comparisons will require running all systems on the same machine.
@jeswr Have you seen this reasoning challenge pass by? https://gist.github.com/justin2004/f9d07adf4e7c2c422be3e0ba92f278d2
Might be interesting to try out in your implementation(s).