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 >