Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
EmfIndex Comparison
This page is intended to compare the two index implementations form different viewpoints such as
- API
- Performance
- Memory Consumption
- How to build a convinient Query API on top of the low level API
Contents
Performance
Indexing
Indexing time
This test measured the time which is needed to index x-times the content of Ecore.ecore. (Containing 393 instances of EObject and 520 references)
|
1000 | 2000 | 3000 |
SAP | 15,4 s | 29,9 s | 45,3 s |
Itemis | 14,6 s | 28,4 s | 43,5 s |
Memory consumption
This test measured the in memory size of the index. In the SAP case, paging was disabled
|
1000 | 2000 | 3000 |
SAP | 136 million bytes | 278 million bytes | 408 million bytes |
Itemis | 169 million bytes | 340 million bytes | 508 million bytes |
Query response time
Query All EObject and all EReferences
|
1000 | 2000 | 3000 |
SAP | 0,3 s | 0,45 s | 0,65 s |
Itemis | 1,4 s | 2,2 s | 3,3 s |
Query all references targeting a certain resource
|
1 | 2 | 4 | 8 | 16 | 32 | 64 | 128 |
SAP | 0,6 ms | 0,6 ms | 0,6 ms | 0,6 ms | 0,6 ms | 0,6 ms | 0,6 ms | 0,6 ms |
Itemis | 5 ms | 537 ms | 3178 ms | 15190 ms | 65177 ms | 268899 ms | 1087066 ms |
Query all instances of "EClass"
|
128 | 256 | 512 | 1024 | 2048 |
SAP | 0,4 ms | 0,8 ms | 1,2 ms | 4 ms | 8,2 ms |
Itemis | 72 ms | 142 ms | 287 ms | 500 ms | 1103 ms |
eObject.getResourceDescriptor() | resource.getEObjects() | resource.getReferences() | reference.getTargetObject() |
7 µs | 104 µs | 220 µs | 12 µs |
Convenient query API
The following proposal can be implemented on top of the low level API to provide a more convenient query API as proposed by Itemis. The basic idea would be to provide a specialized query factory for the convenient queries, which returns wrappers around the low level query objects. The query wrapper would also return a wrapped QueryResult object which in turn wraps the low level descriptors. The following snippet shows an example of the query factory.
public class ConvenientIndexQueryFactory { public ConvenientEObjectQuery<?> createEObjectQuery() { ... } public ConvenientEReferenceQuery<?> createEReferenceQuery() { ... } public ConvenientResourceQuery<ConvenientResourceDescriptor> createResourceQuery() { return new ConvenientResourceQueryImpl<ConvenientResourceDescriptor>(); }
The returned resource query needs to subclass our ResourceQueryImpl class and override the createQueryResult() method.
public class ConvenientResourceQueryImpl<T> extends ResourceQueryImpl<T> implements ConvenientResourceQuery<T> { @Override public QueryResult<T> createQueryResult(QueryExecutorInternal queryExecutor, Iterable<ResourceDescriptor> result) { return ...; // new QueryResult implementation } }
A convenient user may use this API as like as the low level API:
public class ConvenientUser { public void test() { final ConvenientResourceQuery<ConvenientResourceDescriptor> query = new ConvenientIndexQueryFactory().createResourceQuery(); query.uri("hallo"); Index index = ...; index.executeQueryCommand(new QueryCommand() { @Override public void execute(QueryExecutor queryExecutor) { QueryResult<ConvenientResourceDescriptor> execute = queryExecutor.execute(query); } }); } }