Re: MaJorToM version 1.2.0 released

Benjamin Bock <[email protected]> Sat, 16 Apr 2011 14:28:51 +0200
Newsgroups gmane.text.xml.xtm.general
Message-ID <[email protected]>
Hi Lars et al,

we had different results in our benchmarks (which may as well be
unrepresentative).

In our benchmarks MaJorToM and Ontopia where always fastest, often
very close together.
In all of our tests, tinyTiM was the slowest implementation, sometimes
very far off.

Another interesting perspective is memory usage: MaJorToM always won
here over the other two implementations.

Our biggest testcase had several million topics, about the same number
of associations (most of them binary), and 10 times more occurrences.
We have special importers and exporters e.g. for CTM and XTM, which
reduced the import time for an unmerged 1GB XTM from around 6 hours to
less than 1/2 hour compared to the importers which come with TMAPIX.

To increase the performance the first thing to do with MaJorToM is to
take a look at the feature strings [1] and see what features you may
want to switch off. E.g. switching of the history which records all
changes increases the performance by a factor greater than 10 in most
use cases. Earlier implementations had history enabled as default, but
IIRC it's off in the default configuration. You may double-check
nonetheless.

Next thing to look at is type-instance-associations. IIRC, it is off
by default for both tinyTiM and Ontopia. MaJorToM has it enabled by
default. By here, MaJorToM should be faster than tinyTiM for most use
cases.

Another thing to look at is supertype-subtype-associations. To my
knowledge, MaJorToM is the only TMAPI-compatible engine to support
also supertype-subtype natively. Using this API brings you out of
TMAPI 2.0 land, but it gives you another performance boost if you
happen to use the transitive features which will be very likely used
by a TMQL engine on top of a TMAPI engine (which we did).

There are more things one could do, like switching off automerge
during an import and calling removeDuplicates after the import
finishes etc.. I bet Sven Krosse could provide even more optimization
ideas if he intercepts his weekend and vacation which he hopefully
enjoys currently ;-)

Best regards,
Benjamin


[1] http://docs.topicmapslab.de/majortom/#_majortom_api_feature_string

On Fri, Apr 15, 2011 at 11:33 PM, Lars Heuer <[email protected]> wrote:
> [...]
>> Within the last months MaJorToM has matured to an reliable alternative
>> for all topic mappers. It is used in a bunch of projects from the Topic
>
> Acc. to my tests MaJorToM (in TMAPI mode) is the slowest Topic Maps
> (Java) engine (in "memory" mode). Further, it's the engine which fails
> most of all tests.
>
> "My" tests may not count, maybe someone (who is still interested in
> Topic Maps) should found a Topic Maps benchmark project.
>
> Best regards,
> Lars
> --
> Semagia
> <http://www.semagia.com>
>
> <https://twitter.com/larsheuer/> Twitter
> <http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
> <http://tinytim.sourceforge.net/> Open Source Topic Maps engine
> <http://mappa.semagia.com/> Mappa - Python Topic Maps engine
> _______________________________________________
> topicmapmail mailing list
> topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected]
> http://www.infoloom.com/mailman/listinfo/topicmapmail
>