> Experiment needed - on a normal commodity server or a portable, the > limiting factor may not be the CPU, or just the CPU. The system bus > (moving data around) and the persistent storage may be limitations.
On my computer, creating a TDB2 store with tdb2.tdloader from a .nt file 1.1G in size: - read from disk, write to disk: 35K triples per second (as reported by tdb2.tdbloader AVG value) - read from disk, write to tmpfs: 43K AVG triples per second - read from tmpfs, write to tmpfs: 45K AVG triples per second Adding -Xmx3G to the "java" command in tdb2.tdbloader didn't seem to have any effect. On the other hand, I have a thread constantly at 100% Creating the store with the "--graph" argument seems significantly slower than without such argument. I've only tested this for the first case (read disk, write disk) and tdb2.tdbloader reports about 50K AVG triples per second It's not a deep statistic but... if the reported AVG numbers are correct then I guess a slow CPU is the bottleneck for tdb2? I guess the largest improvement would probably be adding multi-threading to tdb2.tdbloader, considering that servers can have more then 10 or 20 cores. Either this or map-reduce.
