Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EmfIndex Comparison"
Line 154: | Line 154: | ||
| resource.getReferences() | | resource.getReferences() | ||
| reference.getTargetObject() | | reference.getTargetObject() | ||
− | |||
|- | |- | ||
− | | 7 µs | + | | 7 µs |
− | | 104 µs | + | | 104 µs |
| 220 µs | | 220 µs | ||
− | | 12 µs | + | | 12 µs |
|} | |} | ||
Line 165: | Line 164: | ||
<br> | <br> | ||
+ | |||
+ | == 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. | ||
+ | |||
+ | <source lang="java"> | ||
+ | public class ConvenientIndexQueryFactory { | ||
+ | |||
+ | public ConvEObjectQuery<?> createEObjectQuery() { | ||
+ | ... | ||
+ | } | ||
+ | |||
+ | public ConvEReferenceQuery<?> createEReferenceQuery() { | ||
+ | ... | ||
+ | } | ||
+ | |||
+ | public ConvResourceQuery<ConvenientResourceDescriptor> createResourceQuery() { | ||
+ | return new ConvenientResourceQueryImpl<ConvenientResourceDescriptor>(); | ||
+ | } | ||
+ | </source> |
Revision as of 04:12, 2 September 2009
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.
public class ConvenientIndexQueryFactory { public ConvEObjectQuery<?> createEObjectQuery() { ... } public ConvEReferenceQuery<?> createEReferenceQuery() { ... } public ConvResourceQuery<ConvenientResourceDescriptor> createResourceQuery() { return new ConvenientResourceQueryImpl<ConvenientResourceDescriptor>(); }